Ежедневный отчёт программиста

[@gandjustas]

ИМХО стендап-митинги эффективнее, на них и забить сложнее, и проигнорировать тоже не выйдет, да и в живом общении можно быстрее выяснить что происходит, чем по переписке.

[@CrazyViper]

Просто автор придумал «стендап митинги» по почте. ИМХО, в случае распределенной команды эффективнее по скайпу: не тратится время на написание, все получают информацию одно временно. Вообще, если не вдаваться в подробности предложения, то статья однобокая: нет глубины анализа проблемы, нет альтернатив, нет описания недостатков выбранного способа.

В случае с такой рассылкой сходу вырисовывается проблемы: я могу просто не читать то, что пишут другие и это никак не контролируется. Чтобы каждый в команде прочитал то, что написала остальная команда нужно явно больше 5 минут. Вы это время оплачиваете?

[@Askofen]

Ежедневные отчёты и стендап-митинги не противоречат друг другу. Более того, у нас использовались и одни, и другие. Просто стендапы проводятся утром и внутри локальной команды, а отчёты доступны всем — и твоей команде, и удалённой команде.

Поначалу мы пытались обойтись только одними стендапами, но было трудно синхронизировать 20 человек в Питере с 15-ю людьми на тихоокеанском побережье — из-за разницы во времени и из-за большого количества людей. В итоге у нас по скайпу синхронизировались только лиды, стендапы проводились только локально, а отчёты — писали все.

[@AlexTest]

При использовании нормальной системы управления проектом (нСУП) такие отчеты просто не нужны!
1. В нСУП всегда видно над чем конкретно сейчас работает разработчик (фильтр по задачам: «разработчик» + статус задачи «в процессе») + приоритеты.
2. В нСУП всегда видно какие задачи закрыл разработчик (фильтр по задачам: «разработчик» + статус задачи «завершено») и кому их передал на проверку/тестирование и т.д.
3. В нСУП всегда видно какие задачи вызвали вопросы или т.н. «блокировки», разработчик просто запрашивает доп. информацию у менеджера проекта в комментариях к задаче. (фильтр: «разработчик» + статус задачи «в ожидании доп. информации/действий») А менеджер проекта всегда видит у себя в аккаунте такие задачи и контролирует предоставление доп. информации и выполнение всех доп. работ для продолжения задачи!
4. В нСУП всегда видно какие задачи будет делать разработчик и когда (фильтр по задачам: «разработчик» + статус задачи «открыта»). Здесь также должна применяться любая схема назначения приоритетов, дат, дедлайнов и т.п.
В общем прекратите заниматься всякими глупостями, придумывать велосипеды рассылки и заставлять разработчиков тратить гораздо больше времени чем 5 минут на бестолковые ежедневные отчеты. Лучше научитесь использовать любую современную систему управления проектами, там есть все эти возможности, а также приучите удаленную команду соблюдать регламент по ведению задач и будет вам счастье! :)

[@Askofen]

Если Вы хотите, чтобы отчёты читал не только менеджер, но и остальные члены команды, то Вам нужно упростить доступ к необходимой информации. Представьте, что у Вас в команде 30 человек, половина которых находится в другой стране и даже на другом континенте. Что проще — обязать всех каждый день просматривать историю изменений в трекере для каждого из 30 сотрудников или же просмотреть 30 коротких писем, которые уже отфильтрованы в специальную папку?

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

[@AlexTest]

Что проще — обязать всех каждый день просматривать историю изменений в трекере для каждого из 30 сотрудников или же просмотреть 30 коротких писем, которые уже отфильтрованы в специальную папку?

Ну зачем вы продолжаете придумываеть себе проблемы, а мне приписываете то, чего я не говорил.
Я не понимаю почему вы думаете, что вся команда (тем более, такая большая команда из 30 человек и более) должна читать ВСЕ отчеты друг друга и просматривать историю ВСЕХ изменений в каком-то там трекере (очевидно подразумевается трекер задач)?
Каждый должен отвечать за свои задачи, а менеджер проекта за общую координацию выполняемых работ — все очень просто! Для этого и созданы системы управления проектами, трекер задач это только маленькая часть такой системы. Там задачи не просто трекаются, а говоря русским языком — отслеживаются, но и управляются с помощью серьезного набора инструментов, вплоть до интеграции с IDE разработчиков и системами контроля версий.
Объяснить как со всем этим работать в одном комментарии не получится — надо писать отдельную статью или даже цикл статей. Но это и не является какой-то там тайной — вся информация есть в интернете.
Еще раз настоятельно рекомендую научиться эффективно использовать какую-нибудь понравившуюся вам серьезную современную систему управления проектами — и у вас отпадет необходимость использовать всякие костыли.

[@Askofen]

Ну зачем вы продолжаете придумываеть себе проблемы, а мне приписываете то, чего я не говорил.

Я далёк от того, чтобы Вам что-нибудь приписывать. Я лишь поясняю, чем наша ситуация отличается от Вашей. Если Вам достаточно, чтобы информацию о том, кто чем занимается получал лишь менеджер, то никто и не спорит, что он может извлечь её из таск трекера. В нашем случае необходимо было, чтобы отчёты просматривало как можно больше людей (в идеале — все инженеры команды). А этого можно добиться, в том числе и упростив доступ к подобной информации. Просмотреть 30 отчётов, которые, к тому же, в e-mail клиенте идут подряд, гораздо быстрее, чем каждому разработчику извлекать такую информацию самостоятельно из системы контроля задач.

Я не понимаю почему вы думаете, что вся команда (тем более, такая большая команда из 30 человек и более) должна читать ВСЕ отчеты друг друга и просматривать историю ВСЕХ изменений в каком-то там трекере (очевидно подразумевается трекер задач)?

Это необходимо, потому что между задачами могут быть скрытые зависимости. Или какая-нибудь задача может быть аналогична другой задаче, уже кем-то решённой. Поэтому бывают полезны комментарии от коллег в стиле: «Подобную задачу я уже решал — посмотри моё решение в таком-то файле или changelist'е» или «Не трогай эту задачу, т.к. её решение зависит от моей текущей задачи. Обожди пару дней, пока я доделываю решение».

Каждый должен отвечать за свои задачи, а менеджер проекта за общую координацию выполняемых работ — все очень просто!

В нашем случае на 30 человек приходилось 2 менеджера (один находился в офисе основной команды, другой — в офисе удалённой команды), 5 лидов (2 — в основном офисе, 3 — в офисе удалённой команды) — и тем не менее, нужна была коммуникация не только между менеджерами и не только между лидами, но и между отдельными инженерами обеих команд. Возможно, причина этого заключалась как в слишком сжатых сроках, отведённых на разработку, так и в том, что имеющийся исходный код был незнаком обеим командам. Тем не менее, мечту о едином менеджере-координаторе, который распределяет работу между всеми остальными членами команды пришлось забыть.

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

Системы управления задачами здесь — оффтопик. Я не пишу о них в данном материале не потому, что не знаю или не умею ими пользоваться, а потому что статья посвящена ежедневным отчётам.

[@AlexTest]

Это необходимо, потому что между задачами могут быть скрытые зависимости. Или какая-нибудь задача может быть аналогична другой задаче, уже кем-то решённой. Поэтому бывают полезны комментарии от коллег в стиле: «Подобную задачу я уже решал — посмотри моё решение в таком-то файле или changelist'е» или «Не трогай эту задачу, т.к. её решение зависит от моей текущей задачи. Обожди пару дней, пока я доделываю решение».

Тааак: Анархия — мать порядка! :) Извиняюсь, но у вас бардак на проекте. В контексте вышесказанного вами — интересно было бы узнать, а сколько вы доплачиваете разработчикам если они дают такие ценные комментарии-указания другим разработчикам или наоборот на сколько штрафуете если не дают? И зачем вам тогда вообще нужны на проекте менеджеры, архитекторы, тимлиды если сами разработчики так лихо друг другом управляют, обеспечивают повторное использование кода, находят зависимости между задачами и т.д. и т.п.? Как вообще при таком подходе можно что-либо серьезно планировать, оценивать сроки-затраты-прибыль, управлять рисками, оценивать производительность подразделений и отдельных членов команды?
Хотел было к своей первой рекомендации (по системам управления проектами, а не задачами, как пишите вы) добавить еще и вторую по классике организации процесса разработки, но пожалуй не буду, да и на вопросы можете не отвечать. На самом деле вам самому когда-нибудь это все надоест и вы либо упорядочите и автоматизируете процесс разработки либо уйдете из этого бизнеса. Искренне желаю удачи и оставаться в бизнесе!

[@progchip666]

У меня пока очень маленькая команда и для отслеживания деятельности её участников вполне хватает системы контроля версий, в которую я требую почаще вносить коммиты. Пол часа на просмотр и обновление проекта вечером и сразу видно кто что сделал.
Тут правда есть один тонки момент — для того чтобы отслеживать работу таким образом руководитель проекта тоже должен быть профи в программировании, а не только степень МБА иметь.

[@Askofen]

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

Например, в нашем случае использовались стендапы, ежедневные отчёты инженеров, синкапы лидов удалённых команд, синкапы менеджеров удалённых команд, ежедневные отчёты менеджеров, система контроля задач (в которой трекались технические задачи), система контроля задач (в которой трекались фичи), ревью кода и т.д.

[@progchip666]

не спорю
Я сам в некоторых проектах ещё прожект менеджер использую. Но это когда кроме софта ещё много железной части в проекте присутствует. И да, мои проекты не слишком большие, в них обычно максиуму вовлечено 5-6 человек.