Тут Мегаплан постепенно приобретает человеческое лицо, и начинает понимать что нельзя “с наскока” внедрить процесс постановки задач, как лампочку Ильича, в каждую избу на деревне. Выскажу и я своё скромное мнение.
Существует две крайности относительно постановки задач: одна из них – полное отсутствие таск-менеджера вообще, передача задач устно, по аське, по е-майлу, на стикерах к монитору. Вторая – запись всего-всего-всего в таск-менеджер, и обсуждение всех подробностей и шагов решения задачи там же в комментариях, даже между людьми сидящими за соседними столами.
В реальности большинство компаний болтаются где-то между, что-то записывая в трекер, а что-то передавая исключительно на словах. Давайте разберёмся, что же там происходит и почему. Для начала – лирическое отступление и правда жизни:
Даже тщательное ведение таск-менеджера не приближает вас к успеху проекта.
Никакие инструменты не приближают вас к успеху проекта. Успех проекта не зависит от качества кода, применения автоматизированного тестирования и кодоанализаторов, процессов непрерывной интеграции, деплоя с миграциями и так далее. Никто в здравом уме не делает большой проект без этих инструментов, но они не являются залогом успеха.
Успех проекта зависит наполовину от того, насколько хорошо сработают люди, его создающие. А на вторую половину – от того, с какими эмоциями его будут использовать клиенты. Поэтому вы должны быть сосредоточены на том, чтобы набрать правильных людей, помочь им сработаться и убирать препятствия с их пути, и в том числе – поддерживать полезные инструменты и на%уй саботировать неполезные. А вот кто есть кто – зависит от вашего конкретного случая.
Вернёмся к теме:
Записывать в таск-менеджер (трекер) нужно:
Когда команда распределена. Если у вас команда и/или заказчики значительно разделены территориально и по рабочему времени, то очевидно рекомендуется записывать задачи и результаты, чтобы передавать их друг другу.
Когда задача – это на самом деле баг. Баг, как сущность, – это формализованно описанная проблема. Есть даже мантра тестировщиков, помощающая составить хорошее описание: что я делал, что я получил, что я ожидал получить. Говоря умными словами – шаги по воспроизведению, полученный результат, ожидаемый [по спецификации] результат. Однозначно записывать, иначе потеряется.
Когда задача ясна от начала до конца. Бывают такие задачи, над которыми не нужно думать, а нужно просто сделать. Добавить такие-то виртуальные хосты под такое-то число сервисов, вот список. От человека требуется взять и накатать рецепты в chef. Не нужно долго думать, достаточно сработать по известному алгоритму, и требуемый результат чётко понятен.
Когда задача содержит много формализованных значений. Например, увеличить максимальную длину логина с 8 до 16 символов, и допускать логины начинающиеся только с маленькой буквы из диапазона [a-z].
Когда исполнитель пьян. Ну, или не пьян, а с похмелья. Или не с похмелья, а всю ночь херачил над другими проектами, а утром вспомнил что нужно идти на работу. Или всю ночь укачивал капризничающего ребёнка. В общем, в тех случаях, когда над ним нужно сидеть и помогать нажимать пальцами на кнопки.
Записывать в таск-менеджер (трекер) НЕ нужно:
Когда задачу лучше сделать прямо сейчас. Как в GTD есть правило – если входящее письмо требует меньше двух минут на решение, то нужно решать сразу, не перекладывая в todo или later. Так и в разработке – если проще обсудить и тут же решить, то надо обсудить и тут же решить. Вспоминаем начало этого поста, если забыли.
Важно, чтобы это реально была задача класса “быстро решить”, а не бравада вашего разработчика в стиле “плавали-знаем”, которая выльется в полдня работы.
Когда задача требует исследования и/или проектирования. Педанты скажут, что надо делать две задачи – на исследование и на реализацию. Если вам так удобно – делайте. Но если вы сами работали программистом, то вы знаете, что в фазе исследования вы можете уже накодить так много пробных вариантов, что фаза реализации превратится по сути в рефакторинг уже сделанной работы. Как теперь отчитываться по двум задачам?
Можно не оформлять исследовательскую работу, но оформить в задачу когда исследование проведено и стало понятно что делать. Но опять же, в большинстве случаев исполнитель уже настолько погрузился в проблему, уже исписал так много листиков с алгоритмами и схемами, что переоформлять это в трекере нет никакого смысла: и так всем понятно (а главное – исполнителю понятно), что надо сделать и как оно будет работать.
Автор этих строк пользуется простым методом, и вам рекомендует: берите свой айфон и фоткайте все эти листики. Или маркерные доски, если там нарисовано. Это и будет документацией, если она вдруг понадобится кому-то из коллег.
Когда задача очевидна. Говоря другими словами, когда мимо неё не пройти, не споткнувшись. Очевидно, что в проекте должен быть процесс деплоя (скрипты, выполняющие выгрузку новой версии в продакшен). Очевидно, что у проекта должны быть группы dev-, stage-, prod-серверов. Очевидно, что когда у интернет-магазина есть корзина, то должен быть и способ фиксации заказов.
Замечание: речь про собственные (внутренние) проекты. Это не подходит, если вы работаете по fix-price и фиксированному ТЗ с внешним заказчиком.
Когда конечный результат не определён. Мой любимый пример – система аутентификации, авторизации, и распределения прав. Не смотря на (казалось бы) универсальный стандарт ACL, я не встречал ни одного проекта, в котором система прав доступа была бы сделана так, чтобы удовлетворять всех от разработчиков до клиентов. Если у вас нет возможности воткнуть какой-то готовый модуль и успокоиться, то единственный вариант – принудить команду запилить конкретное относительно нормальное и легко расширяемое (в будущем) решение. Иначе холивар вырастет на месяц.
Возвращаясь к теме поста, это пример задачи, не имеющей формализованного результата. Понятно, что система авторизации в проекте (в общем случае) должна быть. Понятно также, что на начальных этапах всем по%уй, как она устроена. Это потом, в результате тестовой эксплуатации первых альфа-версий, к ней появятся конкретные требования. Туда ходи, сюда не ходи. Это мочь, это не мочь. Но это только потом, а сейчас, на берегу, у вас есть несколько вариантов:
– привлечь профессиональное проектирование и запроектировать от начала до конца. В большинстве случаев означает бездарно потерять время [/деньги], потому что всё равно половина будет переделана, а вторая половина сразу не подойдёт.
– надавить авторитетом и сформулировать как что должно работать от начала до конца. Говно-вариант, потому что если ваша команда – не роботы, то они и сами смогут выдвинуть встречный десяток альтернативных идей, и будут демотивированы вашим давлением.
– выбрать исполнителя, соответствующего по квалификации, который сам (с небольшими подсказками) выберёт нормальный алгоритм и запилит хорошее расширяемое решение.
По какому варианту пойти – вам должно быть очевидно. И очевидно, что по такой задаче бесполезно записывать в трекер что-то большее чем заголовок “Внедрить подсистему разграничения прав доступа”.
Резюме:
Автор этих строк использует простое правило: если результат формализован и нельзя сделать прямо сейчас – записывать. В иных случаях – на%уй. Как действовать вам – зависит от вашего проекта и команды. Выберите способ, с которым команда будет наиболее продуктивна, и действуйте по нему.
