В данной статье я хочу рассмотреть вопросы эффективности работы программиста.
На тему организации рабочего места, настройки рабочего окружения, тайм-менеджмента уже написано много статей, я хочу осветить проблему эффективности с другой стороны. Статья ориентирована на работников IT-индустрии, работающих на любой позиции и любой должности, однако в качестве наглядного и понятного примера будем рассматривать программиста.
Я затрону проблему эффективности с точки зрения работы внимания на разных этапах выполнения задачи для того, чтобы было более глубокое понимание того, куда именно уходят силы и время при выполнении задачи.
Это позволит вам:
- Лучше понять, куда уходит время при решении задачи
- При оценке задач лучше понимать, куда уходит время и какие риски могут быть при выполнении данной задачи
Дано
В качестве примера возьмем следующее:
Задача отдана программисту в виде полных и однозначно определенных требований. Результатом решения должен быть готовый к использованию и оттестированный код, лежащий в нужной ветке репозитория. Например, “Надо реализовать контрол Y для стартовой страницы”
Как делают обычно
Да, программисты бывают разной квалификации, по этому возьмем некое “среднее”, каждый сделает поправку на себя.
Подход 1
А, это несложная задача, сейчас сяду и сразу закодирую, потестируем и вольем.
При этом часто читается только формулировка задачи. Рассмотрение того, как точно задача будет интегрирована в проект может быть вообще выпущена из рассмотрения.
Подход 2
На бумаге (или в ином виде) прикидывается примерная архитектура, исходя из задания, требований и последующей интеграции задачи и потом начинаем кодить, тестировать и заливать
Оба подхода имеют право на жизнь, но не смотря на то, что они отличаются их объединяет мыслительный процесс, который происходит при решении задачи. И вот на этом я хочу остановиться подробнее. Осознанно или неосознанно (что гораздо чаще) мы проходим следующие этапы:
- Декомпозиция полученной задачи на максимально атомарные
- Проверка, что мы можем выполнить эту атомарную задачу и у нас нету блокирующих факторов. Если требуется - повторно разделить ее на подзадачи
- Выполнение этих атомарных задач
- Проверка того, что поставленная задача решена и мы успешно достигли конечного поставленного результата
Очевидно, что основные усилия уходят на пунктах 1-3 и именно эти этапы следует делать максимально осознанно и упорядоченно.
Этап 1. Декомпозиция - всегда процесс творческий и при недостаточном опыте можно упустить некоторые подзадачи из рассмотрения. И здесь требуется большое сосредоточение внимания.
Этап 2. Проверка. Здесь большинство задач можно решить “на автомате”. То есть “сильно думать” здесь не требуется
Этап 3. Выполнение атомарных задач. Вот это как раз самая коварная часть, потому что одни атомарные задачи могут быть выполнены “на автомате” (например, создание шаблона проекта в среде разработке), в то время, как другие требуют вдумчивой и кропотливой работы с полным и стопроцентным вовлечением в задачу.
И именно в этом очень часто кроются такие вещи, как “долгое” выполнение задачи, которые при первоначальном рассмотрении общей задачи вообще могут не попадать во внимание. (Например, детальное описание интерфейсов или продумывание структур данных для конкретной реализации контрола)
Этап 4 не требует детального пояснения: часто это тестирование или ревью кода.
Теперь, возвращаясь к возможным подходам, понятно, что в подходе 1 все эти этапы собраны в кучу без четкого разделения. Подход 2 в этом отношении лучше.
Рассмотрим теперь более конкретный пример, как все это работает:
Задача: Реализовать кнопку на стартовом экране приложения.
Этап 1:
- Создать таск в системе и бранч в гите
- Понять, мы будем использовать кнопку только из кода или и в визуальном редакторе (от этого будет немного зависеть время реализации кнопки)
- Сделать скелет кода или визуальный скелет, исходя из пункта выше
- Продумать, какие настройки кнопки нужны для формирования нужного внешнего вида
- Описать истерфейсы для конфигурации внешнего вида кнопки
- Если надо, подумать, как будет работать спиннер и описать интерфейс для спиннера
- Подумать, как будет осуществляться работа пользователя с кнопкой (будет ли только 1 клик, или надо еще двойной клик, жест удержания и пр.)
- Описать это в виде интерфейсов
- Подумать, знаю ли я все, чтобы просто закодировать все, что выше (как работают фреймы, автолайаут, настраиваются цвета, показывается спикер и пр.)
- Если я чего-то не знаю - записать что именно неизвестно и почитать доки или спросить это у коллег
- Все закодировать
- Потестировать контрол в приложении
- Поправить баги, если есть
Критично: Делая все “на автомате” мы можем что-то упустить из виду, по этому рекомендуется максимально сосредоточиться при выполнении этого этапа
Этап 2:
Здесь просто надо пройтись по списку из этапа 1 и проверить что у нас нету брокеров и все реализуемо.
Если требуется, то уточнить время, которое потребуется для выполнения работы.
Этап 3:
Делаем все по списку
Критично: Далеко не все пункты из этапа 1 можно делать “на автомате”. На определенных этапах требуется полное сосредоточение, даже есть формулировка атомарной задачи очень короткая.
Этап 4:
Тестируем и подливаем
Краткое резюме и выводы:
- Любая задача должна разбиваться на подзадачи
- Разные подзадачи требуют различной степени сосредоточения внимания и времени решения. Непринятие во внимание этого факта приводит к чересчур долгой разработке или недооценке задачи.
- Этапы 1-4 осознанно или неосознанно происходят при решении любой задачи. Так что, сделав эти этапы более осознанными при решении задач можно добиться значительного роста продуктивности своей работы.
