Цели и задачи
- Своевременно обнаруживать препятствия, с которыми столкнулись инженеры при выполнении своих заданий.
- Находить зависимости между заданиями разных инженеров.
- Своевременно определять, какой задачей занимается инженер – той, что поставил ему менеджер или ведущий программист, или той, что он выдумал себе сам.
- Объективно оценивать результаты работы каждого сотрудника.
Правила
Менеджер проекта создаёт специальную группу рассылки «Ежедневные Отчёты» и подписывает на неё всех участников проекта. Каждый инженер в конце своего рабочего дня тратит 5 минут времени для того, чтобы написать ежедневный отчёт и отправить его на группу рассылки.
Шаблон отчёта
В ежедневном отчёте сотрудник должен последовательно ответить на три вопроса:
1. Что блокирует мою работу?
При ответе на этот вопрос инженер перечисляет риски, угрозы, препятствия или зависимости, которые блокируют его работу над текущим заданием.
ПРИМЕРЫ:
Задача «67 – Навигационная система – Главное меню – Обновить иконки» заблокирована из-за отсутствия новых иконок
Задача «83 – Навигационная система – Поиск по почтовому индексу – Добавить экран поиска по почтовому индексу» не может быть завершена, т.к. работа над задачей «82 – Навигационная система – Разработать модуль поиска по почтовому индексу» ещё не начата
2. Что я делал сегодня?
Отвечая на этот вопрос, инженер перечисляет задания, которыми он занимался в текущий рабочий день. Информация о задании должна включать идентификатор задания, название и, по-возможности, гиперссылку на его описание в системе контроля заданий. Название позволит читателю отчёта (менеджеру или другому инженеру) составить представление о том, чем занимался данный человек. Идентификатор задания и гиперссылка помогут быстро найти дополнительную информацию по заданию в системе контроля заданий.
ПРИМЕРЫ:
119 – Навигационная система – Построение маршрута – Разобраться, почему не используется КАД при построении маршрута от пр. Непокорённых до Ладожского вокзала при включённой оптимизации по времени
91 – Навигационная система – Поиск адреса – Разобраться, почему находятся несколько пересечений Невского пр. и Казанской ул.
3. Что я собираюсь делать завтра?
Отвечая на третий вопрос, инженер перечисляет задания, к которым он собирается приступить на следующий рабочий день, или же указывает, что задания отсутствуют, если заданий нет.
ПРИМЕРЫ:
131 – Навигационная система – Навигация – При движении по маршруту стрелка не должна перескакивать на перпендикулярные улицы и менять своё направление на 90 градусов
107 – Навигационная система – Навигация – Разобраться, почему при движении по Гражданскому пр. стрелка прилипает не к основному дорожному элементу, а к «карману»
Комментарии (11)
AlexTest
30.03.2015 02:57+4При использовании нормальной системы управления проектом (нСУП) такие отчеты просто не нужны!
1. В нСУП всегда видно над чем конкретно сейчас работает разработчик (фильтр по задачам: «разработчик» + статус задачи «в процессе») + приоритеты.
2. В нСУП всегда видно какие задачи закрыл разработчик (фильтр по задачам: «разработчик» + статус задачи «завершено») и кому их передал на проверку/тестирование и т.д.
3. В нСУП всегда видно какие задачи вызвали вопросы или т.н. «блокировки», разработчик просто запрашивает доп. информацию у менеджера проекта в комментариях к задаче. (фильтр: «разработчик» + статус задачи «в ожидании доп. информации/действий») А менеджер проекта всегда видит у себя в аккаунте такие задачи и контролирует предоставление доп. информации и выполнение всех доп. работ для продолжения задачи!
4. В нСУП всегда видно какие задачи будет делать разработчик и когда (фильтр по задачам: «разработчик» + статус задачи «открыта»). Здесь также должна применяться любая схема назначения приоритетов, дат, дедлайнов и т.п.
В общем прекратите заниматься всякими глупостями, придумыватьвелосипедырассылки и заставлять разработчиков тратить гораздо больше времени чем 5 минут на бестолковые ежедневные отчеты. Лучше научитесь использовать любую современную систему управления проектами, там есть все эти возможности, а также приучите удаленную команду соблюдать регламент по ведению задач и будет вам счастье! :)
Askofen Автор
30.03.2015 16:07Если Вы хотите, чтобы отчёты читал не только менеджер, но и остальные члены команды, то Вам нужно упростить доступ к необходимой информации. Представьте, что у Вас в команде 30 человек, половина которых находится в другой стране и даже на другом континенте. Что проще — обязать всех каждый день просматривать историю изменений в трекере для каждого из 30 сотрудников или же просмотреть 30 коротких писем, которые уже отфильтрованы в специальную папку?
В общем, наш подход заключается в том, что каждый работник должен упрощать работу не только себе, но и своим коллегам.AlexTest
30.03.2015 20:53Что проще — обязать всех каждый день просматривать историю изменений в трекере для каждого из 30 сотрудников или же просмотреть 30 коротких писем, которые уже отфильтрованы в специальную папку?
Ну зачем вы продолжаете придумываеть себе проблемы, а мне приписываете то, чего я не говорил.
Я не понимаю почему вы думаете, что вся команда (тем более, такая большая команда из 30 человек и более) должна читать ВСЕ отчеты друг друга и просматривать историю ВСЕХ изменений в каком-то там трекере (очевидно подразумевается трекер задач)?
Каждый должен отвечать за свои задачи, а менеджер проекта за общую координацию выполняемых работ — все очень просто! Для этого и созданы системы управления проектами, трекер задач это только маленькая часть такой системы. Там задачи не просто трекаются, а говоря русским языком — отслеживаются, но и управляются с помощью серьезного набора инструментов, вплоть до интеграции с IDE разработчиков и системами контроля версий.
Объяснить как со всем этим работать в одном комментарии не получится — надо писать отдельную статью или даже цикл статей. Но это и не является какой-то там тайной — вся информация есть в интернете.
Еще раз настоятельно рекомендую научиться эффективно использовать какую-нибудь понравившуюся вам серьезную современную систему управления проектами — и у вас отпадет необходимость использовать всякие костыли.Askofen Автор
30.03.2015 21:57Ну зачем вы продолжаете придумываеть себе проблемы, а мне приписываете то, чего я не говорил.
Я далёк от того, чтобы Вам что-нибудь приписывать. Я лишь поясняю, чем наша ситуация отличается от Вашей. Если Вам достаточно, чтобы информацию о том, кто чем занимается получал лишь менеджер, то никто и не спорит, что он может извлечь её из таск трекера. В нашем случае необходимо было, чтобы отчёты просматривало как можно больше людей (в идеале — все инженеры команды). А этого можно добиться, в том числе и упростив доступ к подобной информации. Просмотреть 30 отчётов, которые, к тому же, в e-mail клиенте идут подряд, гораздо быстрее, чем каждому разработчику извлекать такую информацию самостоятельно из системы контроля задач.
Я не понимаю почему вы думаете, что вся команда (тем более, такая большая команда из 30 человек и более) должна читать ВСЕ отчеты друг друга и просматривать историю ВСЕХ изменений в каком-то там трекере (очевидно подразумевается трекер задач)?
Это необходимо, потому что между задачами могут быть скрытые зависимости. Или какая-нибудь задача может быть аналогична другой задаче, уже кем-то решённой. Поэтому бывают полезны комментарии от коллег в стиле: «Подобную задачу я уже решал — посмотри моё решение в таком-то файле или changelist'е» или «Не трогай эту задачу, т.к. её решение зависит от моей текущей задачи. Обожди пару дней, пока я доделываю решение».
Каждый должен отвечать за свои задачи, а менеджер проекта за общую координацию выполняемых работ — все очень просто!
В нашем случае на 30 человек приходилось 2 менеджера (один находился в офисе основной команды, другой — в офисе удалённой команды), 5 лидов (2 — в основном офисе, 3 — в офисе удалённой команды) — и тем не менее, нужна была коммуникация не только между менеджерами и не только между лидами, но и между отдельными инженерами обеих команд. Возможно, причина этого заключалась как в слишком сжатых сроках, отведённых на разработку, так и в том, что имеющийся исходный код был незнаком обеим командам. Тем не менее, мечту о едином менеджере-координаторе, который распределяет работу между всеми остальными членами команды пришлось забыть.
Для этого и созданы системы управления проектами, трекер задач это только маленькая часть такой системы.
Системы управления задачами здесь — оффтопик. Я не пишу о них в данном материале не потому, что не знаю или не умею ими пользоваться, а потому что статья посвящена ежедневным отчётам.AlexTest
31.03.2015 04:06Это необходимо, потому что между задачами могут быть скрытые зависимости. Или какая-нибудь задача может быть аналогична другой задаче, уже кем-то решённой. Поэтому бывают полезны комментарии от коллег в стиле: «Подобную задачу я уже решал — посмотри моё решение в таком-то файле или changelist'е» или «Не трогай эту задачу, т.к. её решение зависит от моей текущей задачи. Обожди пару дней, пока я доделываю решение».
Тааак: Анархия — мать порядка! :) Извиняюсь, но у вас бардак на проекте. В контексте вышесказанного вами — интересно было бы узнать, а сколько вы доплачиваете разработчикам если они дают такие ценные комментарии-указания другим разработчикам или наоборот на сколько штрафуете если не дают? И зачем вам тогда вообще нужны на проекте менеджеры, архитекторы, тимлиды если сами разработчики так лихо друг другом управляют, обеспечивают повторное использование кода, находят зависимости между задачами и т.д. и т.п.? Как вообще при таком подходе можно что-либо серьезно планировать, оценивать сроки-затраты-прибыль, управлять рисками, оценивать производительность подразделений и отдельных членов команды?
Хотел было к своей первой рекомендации (по системам управления проектами, а не задачами, как пишите вы) добавить еще и вторую по классике организации процесса разработки, но пожалуй не буду, да и на вопросы можете не отвечать. На самом деле вам самому когда-нибудь это все надоест и вы либо упорядочите и автоматизируете процесс разработки либо уйдете из этого бизнеса. Искренне желаю удачи и оставаться в бизнесе!
progchip666
30.03.2015 10:36У меня пока очень маленькая команда и для отслеживания деятельности её участников вполне хватает системы контроля версий, в которую я требую почаще вносить коммиты. Пол часа на просмотр и обновление проекта вечером и сразу видно кто что сделал.
Тут правда есть один тонки момент — для того чтобы отслеживать работу таким образом руководитель проекта тоже должен быть профи в программировании, а не только степень МБА иметь.Askofen Автор
30.03.2015 14:13В большой и распределённой команде для контроля используют не один какой-нибудь инструмент, а сразу несколько независимых инструментов. И каждый из этих инструментов помогает проверить и дополнить информацию, полученную благодаря другому инструменту.
Например, в нашем случае использовались стендапы, ежедневные отчёты инженеров, синкапы лидов удалённых команд, синкапы менеджеров удалённых команд, ежедневные отчёты менеджеров, система контроля задач (в которой трекались технические задачи), система контроля задач (в которой трекались фичи), ревью кода и т.д.progchip666
30.03.2015 21:24не спорю
Я сам в некоторых проектах ещё прожект менеджер использую. Но это когда кроме софта ещё много железной части в проекте присутствует. И да, мои проекты не слишком большие, в них обычно максиуму вовлечено 5-6 человек.
gandjustas
ИМХО стендап-митинги эффективнее, на них и забить сложнее, и проигнорировать тоже не выйдет, да и в живом общении можно быстрее выяснить что происходит, чем по переписке.
CrazyViper
Просто автор придумал «стендап митинги» по почте. ИМХО, в случае распределенной команды эффективнее по скайпу: не тратится время на написание, все получают информацию одно временно. Вообще, если не вдаваться в подробности предложения, то статья однобокая: нет глубины анализа проблемы, нет альтернатив, нет описания недостатков выбранного способа.
В случае с такой рассылкой сходу вырисовывается проблемы: я могу просто не читать то, что пишут другие и это никак не контролируется. Чтобы каждый в команде прочитал то, что написала остальная команда нужно явно больше 5 минут. Вы это время оплачиваете?
Askofen Автор
Ежедневные отчёты и стендап-митинги не противоречат друг другу. Более того, у нас использовались и одни, и другие. Просто стендапы проводятся утром и внутри локальной команды, а отчёты доступны всем — и твоей команде, и удалённой команде.
Поначалу мы пытались обойтись только одними стендапами, но было трудно синхронизировать 20 человек в Питере с 15-ю людьми на тихоокеанском побережье — из-за разницы во времени и из-за большого количества людей. В итоге у нас по скайпу синхронизировались только лиды, стендапы проводились только локально, а отчёты — писали все.