Если ты дурак — записывай, как делаю это я
В одной из компаний, где я работал, была очень строгая отчётность. Все рабочие часы должны были быть закрыты в отчётности какой-то задачей, а отчёты сдавались ежедневно. В общем, человек ко всему привыкает, и вполне можно было вспомнить, чем ты занимался сегодняшний день и всё расписать. Но однажды нас попросили дополнительно составить такую отчётность за предыдущие полтора месяца. Естественно, такое пожелание вызвало некоторые затруднения у сотрудников.
Для меня же это выполнить это требование было довольно легко. Просто у меня всё записано. Каждый рабочий день.
Отчётность позволяет оценивать свою эффективность
Кто-то обновляет репозиторий каждый день, кто-то не уходит, пока не завершит задачу. Ежедневные отчёты выглядят чем-то вопиющим только в отрыве от этого ряда. От себя могу сказать, что подобная практика очень сильно мотивирует сосредоточиться на работе, и я продолжил составлять отчёты даже когда перешёл на другую работу.
Что ты скажешь себе по окончании трудового дня, если у тебя список задач пустой? Хорошо, если день завершился решением задачи, а если нет? Чем ты вообще занимался сегодня, на что потратил своё время?
Теперь можно проанализировать свой рабочий день, понять, на что уходит время, и тратить время более эффективно.
Учёт позволяет выделить съедающие время задачи
Как-то, ещё до внедрения этой схемы, когда я работал на фрилансе, я не понимал, почему за большое время решается так мало задач. Я подозревал, что я много разговариваю с потенциальными клиентами, но когда я стал фиксировать это время, я поразился, насколько это были громадные потери! Тогда я ограничил своё общение с потенциальными заказчиками десятью минутами, тогда как ранее мог разговаривать с ними до часа, а ведь они могли и не вернуться.
Эффективность работы сразу намного возросла.
Отчётность позволяет вести базу знаний
Кроме этого, записываются не только задачи, но и методы их решения, что позволяет накапливать опыт и использовать эти решения в дальнейшем, даже если прошло несколько лет. Особенно это полезно для разработчика широкого профиля, поскольку языков и технологий много, решение задачи можно себе представлять, а вот конкретный синтаксис может забываться, и подобные базы знаний, в которые превращаются эти отчёты, становятся весьма полезными.
Ведение отчётности не тратит, а экономит время
Может показаться, что ведение базы своих действий занимает очень много времени, но это не так. Когда мне нужно было это оценить, в своих задачах я стал отмечать и то время, которое тратилось на ведение отчётов. И в среднем это время оказалось равным 25 минут в рабочий день. С учётом того, что отчёты зачастую составлялись весьма общирные, и это давало возможность использовать наработки повторно, это в конечном итоге оборачивалось не потерей времени, а наоборот, его экономией.
Микрошаги
По прошествии времени я усовершенствовал эту систему, и преобразовал её в метод, который я назвал микрошагами. Например, нужно применить некое решение, которое уже описано полгода назад. Но условия могут меняться, и может быть непонятным, почему на том этапе именно это решение было применено, а не какое-то другое. Эффективность повторного использования решения снижалась. Тогда я ввёл причинно-следственный элемент в отчётность, ограничил одно описываемое действие двадцатью минутами работы. Это был эксперимент, но он удался!
Оказалось, любую задачу можно разбить на такие подзадачи и уложить её в требуемое время. Да, это первое требование для эффективного решения задач, разбиение на подзадачи, но я, дополнительно, добавил к подзадачам причины, по которой они делаются, и организовал вложенную структуру, продвигаясь по которой, можно проследить, почему было применено то или иное решение.
Страх узнать правду
А ещё это позволяет оценивать собственную эффективность, и конкретизировать, в чём именно нужно подтянуть свои знания, если какой-то микрошаг занимает неоправданно большое время по сравнению с тем, какое должен был занимать. Конечно, для этого нужно не бояться взглять в глаза той правде, которую покажет собственная отчётность.
Пример микрошагов
Пример микрошагов. Информационно данный конкретный пример не имеет никакого смысла кроме разработчиков данного приложения. Этого пример только показывает, каким образом оформляются микрошаги для решения некоей задачи.
Если микрошаги находятся на одном уровне, то они возникали и решались последовательно. Если происходит переход на один уровень вложенности, это означает, что для выполнения этого микрошага нужно выполнить другие микрошаги, и после их выполнения, решится и задача более высокого уровня. Если в какой-то момент происходит переход на меньший уровень вложенности, значит, с помощью вложенных микрошагов выполнена более вышестоящая задача, которая находится на том же уровне вложенности, на который проихошёл переход.
В данной приведённой для примера задаче, нужно было исправлить null-значения в базе данных мобильного приложения, и проверить его работу, но так как приложение на одном из мобильных устройств вылетело, пришлось идти на сервер и выяснить под каким логином в это приложение нужно заходить, в данном случае это было важно. На втором мобильном приложении оказалось достаточно просто исправить базу.
задача передать данные в систему с мобильного устройства.
включаем отладку usb на устройстве, долго подцепляется
забираем базу
adb pull /sdcard/mobapp/mobapp.db
ищем null, находим, замечаем что время MNGFA=0 тогда как в других пройденных точках оно всегда порядка 30-60. может быть в этом дело.
db browser for sqlite
бэкапим базу с ошибкой
исправляем и загружаем базу обратно на устройство
попытка передать, приложение вылетает. версия 1.2.2.
после перезагрузки приложения нужно в него зайти.
нужно знать под каким логином.
это можно узнать если посмотреть на сервере логи какой последний пользователь логинился с этого устройства.
в логах mosquitto нет тела сообщения а id устройства именно там
старый лог /var/log/srvapp/server.log больше не действует.
нужно смотреть с помощью journalctl под root
какая функция логина?
- в документации
journalctl -u srvapp.service | grep "14F0-F610-MOBILE-ID" | grep -A2 "Z_MB_IF_FUNCNAME"
пользователь: "ZID":"12345678"
переданы данные:
ng.log4j.Log - # Topic: XXYYZZ/ERP/Z_MB_IF_FUNCNAME
то же для второго устройства:
перезагрузка не потребовалась, приложение не выключалось, поэтому не было нужды выяснять под каким логином заходить.
Использование микрошагов для уяснения пробелов в знаниях
Анализ микрошаговой отчётности позволяет выявить узкие места в системе знаний разработчика, и, по-идее, дальнейшим развитием этой системы будет систематизация этих узких мест и уделение времени на устранение пробелов в этих областях. Само выявление не является трудной задачей: нужно увидеть, какие шаги требуют дополнительных действий и занимают достаточно времени для их решения.
Похожие решения
Прошу давать ссылки на подобные существующие практики.
Автор: Олег Петренко
