Если ты дурак — записывай, как делаю это я


В одной из компаний, где я работал, была очень строгая отчётность. Все рабочие часы должны были быть закрыты в отчётности какой-то задачей, а отчёты сдавались ежедневно. В общем, человек ко всему привыкает, и вполне можно было вспомнить, чем ты занимался сегодняшний день и всё расписать. Но однажды нас попросили дополнительно составить такую отчётность за предыдущие полтора месяца. Естественно, такое пожелание вызвало некоторые затруднения у сотрудников.

Для меня же это выполнить это требование было довольно легко. Просто у меня всё записано. Каждый рабочий день.

Отчётность позволяет оценивать свою эффективность


Кто-то обновляет репозиторий каждый день, кто-то не уходит, пока не завершит задачу. Ежедневные отчёты выглядят чем-то вопиющим только в отрыве от этого ряда. От себя могу сказать, что подобная практика очень сильно мотивирует сосредоточиться на работе, и я продолжил составлять отчёты даже когда перешёл на другую работу.

Что ты скажешь себе по окончании трудового дня, если у тебя список задач пустой? Хорошо, если день завершился решением задачи, а если нет? Чем ты вообще занимался сегодня, на что потратил своё время?

Теперь можно проанализировать свой рабочий день, понять, на что уходит время, и тратить время более эффективно.

Учёт позволяет выделить съедающие время задачи


Как-то, ещё до внедрения этой схемы, когда я работал на фрилансе, я не понимал, почему за большое время решается так мало задач. Я подозревал, что я много разговариваю с потенциальными клиентами, но когда я стал фиксировать это время, я поразился, насколько это были громадные потери! Тогда я ограничил своё общение с потенциальными заказчиками десятью минутами, тогда как ранее мог разговаривать с ними до часа, а ведь они могли и не вернуться.
Эффективность работы сразу намного возросла.

Отчётность позволяет вести базу знаний


Кроме этого, записываются не только задачи, но и методы их решения, что позволяет накапливать опыт и использовать эти решения в дальнейшем, даже если прошло несколько лет. Особенно это полезно для разработчика широкого профиля, поскольку языков и технологий много, решение задачи можно себе представлять, а вот конкретный синтаксис может забываться, и подобные базы знаний, в которые превращаются эти отчёты, становятся весьма полезными.

Ведение отчётности не тратит, а экономит время


Может показаться, что ведение базы своих действий занимает очень много времени, но это не так. Когда мне нужно было это оценить, в своих задачах я стал отмечать и то время, которое тратилось на ведение отчётов. И в среднем это время оказалось равным 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
то же для второго устройства:
	перезагрузка не потребовалась, приложение не выключалось, поэтому не было нужды выяснять под каким логином заходить.

Использование микрошагов для уяснения пробелов в знаниях


Анализ микрошаговой отчётности позволяет выявить узкие места в системе знаний разработчика, и, по-идее, дальнейшим развитием этой системы будет систематизация этих узких мест и уделение времени на устранение пробелов в этих областях. Само выявление не является трудной задачей: нужно увидеть, какие шаги требуют дополнительных действий и занимают достаточно времени для их решения.

Похожие решения


Прошу давать ссылки на подобные существующие практики.