Чи можуть щоденні звіти знижувати продуктивність розробника? [зачинено]

В іншому запитанні я запитав про те, чому розробникам не подобається щоденна роздратування . Ми поговорили з розробниками, і ми вирішили не затримувати щоденний скрап деякий час (щоб спробувати його та налаштувати scrum у нашій першій спробі). Це результат консультацій з розробниками безпосередньо.

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

Як альтернатива щоденній розбивці, ми роздумуємо над тим, щоб попросити розробників надавати щоденні звіти з такими умовами:

1. Не потрібно дотримуватися будь-якого конкретного формату. Приймається кожен формат.
2. Навіть якщо робота не виконана, ми хочемо почути кількість прогресу.
3. Не потрібно згадувати час, витрачений на кожне завдання.
4. Слід зазначити перешкоди розвитку та координаційні вимоги.
5. Не потрібно одержимим щоденними звітами. Це не сприймається так суворо.

Ви вважаєте, що це може знизити їх продуктивність? Чи мали ви щоденний досвід звітів? Чи є у вас якісь пропозиції, щоб ми могли переконатися, що ми не керуємо мікроконтролем ?

Як альтернатива щоденній розбивці, ми роздумуємо над тим, щоб попросити розробників надавати щоденні звіти з такими умовами:

Яка жахлива ідея.

Ви вважаєте, що це може знизити їх продуктивність?

Так.

Чому? Словесна презентація на зборах поєднує в собі написання і н "прочитання" звіту в одній супутній діяльності. Говорити плюс слухати. Завершено і с. На питання відповів відразу.

Написання звіту - це марна трата часу, оскільки виникнуть питання, і вам доведеться переглянути звіт з людьми, які (а) мають запитання та (б) насправді не читали.

Щоденні звіти не читатимуться. Вони швидко переходять до шуму.

"Не потрібно одержимих щоденними звітами". У такому випадку навіщо їх робити?

Чи є у вас якісь пропозиції, щоб ми могли переконатися, що ми не управляємо мікроменеджерами?

Так. Майте щоденну стійку. Проходить кілька хвилин, і ви закінчите.

Якщо ваш щоденний режим очікування займає більше декількох (15?) Хвилин, ви ділитеся занадто багато деталей і вам потрібно запланувати окремі зустрічі для цих деталей. Щоденні стоячи легко зробити. Після 2-х хвилинного резюме, все інше, мабуть, деталі, не для всієї команди, і його потрібно перенести на подальшу зустріч. Зустріч переходить до фокусу наступної людини протягом дня.

Я робив це раніше, але вранці, на відміну від кінця дня. Зазвичай на це потрібно було менше п'яти хвилин, так що ні, я не можу зрозуміти, як було б зменшення продуктивності розробника. Приємним, що робити це вранці, було те, що воно змусило задуматися над тим, що ти збираєшся робити решту дня.

Сказавши, що ...

Ми виявили, що це було більше разів, ніж ні, це був не найефективніший спосіб спілкування того, що ми робили попереднього дня, і над тим, що ми працювали в цей день. Чому? Люди взагалі їх не читали. Це було заплановане завдання Outlook, тому кожен надсилав їх щодня, але або їх зашпаровували, або просто пропускали (крім випадків, коли це стосується керівництва чи управління).

Ми з'ясували, що щоденні заходи були набагато ціннішими, оскільки люди, як правило, слухали один одного. Крім того, якщо виникло б непорозуміння, то воно і там зминеться, що трапляється скоріше, ніж хтось відповідає на щоденний електронний лист, щоб задати подальші запитання.

Чесно кажучи, дозволяти будь-кому звітуватись без обмежень, здається, занадто далеко до ліберальної сторони рівняння. Де я працюю, ми йдемо по колу, і кожен розробник дає наступне:

1. Що було зроблено напередодні. Не всі крихітні деталі, але в цілому.
   • Якщо вищезазначене не закінчено, якщо ні, то, що потрібно, щоб закінчити і скільки часу це займе.
   • Якщо вищезазначене буде закінчено, яке наступне завдання, що потрібно, і час, який це займе.
2. Блокатори. Якщо ви працюєте над Foo, який залежить від Bar, і Bar не закінчено, це потрібно зробити зрозумілим.

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

ІМО будь-який тип щоденних зустрічей / звітів знижує продуктивність, тому що, чесно кажучи, смердить від управління мікроекраном. Так, я знаю про Scrum тощо, і вони не надто погані, якщо вони оновлюються коротким статусом ("Ей, як надходить Project X?"), Але я твердо вважаю, що професійним розробникам це ображати, щоб тримати вкладки нас на такому низькому рівні; це схоже на використання табельних карток, щоб переконатися, що ми знаходимось в офісі 8 годин на день, або переконавшись, що немає стін, щоб ви могли шпигувати за комп'ютерами людей, щоб побачити, які вікна вони відкриті в даний момент часу.

Якщо вам доведеться вести всі вкладки, щоб переконатися, що вони працюють, це означає, що ви їм не довіряєте. Якщо ви їм не довіряєте, на роботі виникає більша проблема, ніж проблема, про яку ви переживаєте.

Моя команда займається сутичками вже близько року. До цього у нас були дві зустрічі на тиждень, під час яких кожен член команди повідомляв про свою діяльність за попередні 2, 3 дні. Кожна зустріч тривала від 30 хвилин до 1 години. У випадку, якщо нам знадобився обмін інформацією та координація нашої роботи, ми просто звикли підходити до колег і говорити з ними (що ми, звичайно, робимо).

Зараз, коли ми робимо суперечки, у нас часто виникає враження, що одна зустріч на день (хоча вона триває лише 15 хвилин) - це занадто багато. Часто доповіді деяких членів зводяться до: "Нічого нового з вчорашнього дня". У нас часто виникало враження, що схема «2 зустрічі на тиждень» була більш ефективною.

Ще одним недоліком є ​​те, що щоденна зустріч - це запланована перерва (див., Наприклад , статтю Пола Грема , пункт 1. Уникайте відволікань): оскільки ви знаєте, що перерва настане, перед початком зустрічі ви не збираєтеся починати нічого складного (щоденні зустрічі можуть відбуватись півтори години після того, як одна розпочала роботу).

І останнє, але не в останню чергу, хоча ранні відгуки мають переваги («О, ви працюєте над цією проблемою, ми повинні її обговорити!»), Іноді ефективніше розпочати дискусію лише тоді, коли ви вже організували свої ідеї в думці , у вас є конкретні питання, і ви відчуваєте готовність до обговорення. Натомість щоденні звіти швидко можуть спричинити багато непотрібних та неструктурованих мозкових штурмів. Отже, остерігайтеся занадто раннього зворотного зв’язку: це може вас збентежити і уповільнити.

Отже: у деяких випадках щоденні звіти дійсно знижували нашу продуктивність. У середньому я не маю відчуття, що вони зробили нашу роботу більш ефективною.

ОНОВЛЕННЯ

Я написав свою оригінальну відповідь пару років тому, а тим часом перейшов на перелік команд. У моїй нинішній команді ми проводимо щоденні зустрічі на вимогу, тобто коли відчуваємо, що нам потрібно коротке оновлення статусу. Отже, кожен день є можливість провести таку зустріч, але ми цього не робимо, якщо її ніхто не просить. У нас є щотижнева ретроспективна зустріч. Це в основному дуже схоже на підхід, який ми спочатку використовували в моїй попередній, не спритній команді: фіксовані щотижневі зустрічі плюс додаткові зустрічі на вимогу протягом решти тижня.

Якщо ви дійсно хочете, щоб це було грубим статусом, і помітити будь-які перешкоди, найкращий спосіб - попросити їх короткий "щоденний електронний лист". Якщо ви зробите занадто великий наголос на цьому або складете список того, що він повинен / не повинен містити, то принаймні деякі ваші дияволи витратять додатковий час на його розробку для задоволення вимог. Замість цього просто попросіть простий електронний лист. Коли щодня з'являються речі, кажіть такі речі, як "о, покладіть це на свій кінець дня електронною поштою", і якщо ви отримаєте по-справжньому довгий електронний лист, згадайте випадково "вам не потрібно бути таким докладним кожен день".

Дуже корисно зрозуміти мету будь-якої зустрічі чи доповіді, особливо тієї, що робиться кожен день. Ви кажете, що причина:

ми не хочемо втрачати добрих частин щоденної сутички, як, наприклад, отримувати шанс координувати розробників щодня,

Що ви розумієте під розробниками координат ? Яка робота потребує координації, а розробники та їх керівники не координувались спеціально? Чи, можливо, ви могли б визначити завдання, які потребують координації, і спілкуватися лише в тих випадках?

або спостерігати за ходом роботи, як ключовий показник ефективності, щоб вчасно вжити заходів.

Багато хороших KPI (наприклад, час відгуку на сайті або кількість критичних помилок) буде механічно вимірюваним, і вам не потрібно накладати витрати розробникам, щоб це зробити.

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

Однак, схоже, не застосовуючи формат щоденних звітів, ви ускладнюєте читання та обробку звітів як менеджерам, так і колегам-розробникам, тим самим загострюючи проблему втраченого часу розробника.

Якщо ви вирішили рухатися вперед із щоденними звітами для своїх розробників, я можу запропонувати використовувати внутрішній wiki замість звітів електронної пошти? Таким чином, ви не спамуєте поштові скриньки людей, зберігаючи історію щоденних статусів кожного.

Чудова ідея налаштувати ваші Agile методи, щоб вони підходили вам - настільки кудо для цього.

Отже, щоденні звіти, натомість, я б сказав, що це не набагато краще, ніж щоденна зустріч, це все одно той самий підхід "скажи мені, що ти робиш", ти щойно змусив усіх написати це, а не говорити.

Ось альтернативний підхід: замість того, щоб використовувати ці методи 'опитування', коли ви запитуєте у кожного розробника про його статус, ви використовуєте метод "push". Якщо у розробника немає нічого особливого, щоб повідомити, вони цього не роблять, вони повинні повідомляти про будь-які проблеми та прогрес у міру їх виникнення. Отже, коли вони заповнюють модуль, вони повинні надіслати електронною поштою всій команді, яка його закінчила, його в SCM, де можна знайти документацію, і короткий підсумок того, що це, як він працює та / або як користуватися це. Якщо у них є проблеми, вони повинні надіслати електронною поштою команду з проханням про допомогу, допомогу чи поради. (так, як колись, коли команди добре спілкувались без мікроуправління, яким ми страждаємо сьогодні)

ви побачите, що це набагато продуктивніше та конструктивніше. Ви не отримаєте безглузді звіти заради них, і ви отримаєте більш вмотивовану команду, оскільки всі люблять інформувати своїх ровесників про свою роботу.

Я також погоджуюся з тим, що погана ідея замінювати щоденні етапи роботи звітом. Щоденний стенд-ап - це прекрасне місце для вокалізації ідей та проблем. Це одна з причин, що мені подобається стара хороша дошка (яку ми використовуємо разом із Jira + Greenhopper). Дошка - це місце, де група «тусується» та обмінюється інформацією, все є, усе видно, всі рухаються та змінюють наліпки, над якими працювали, це також дуже весело.

Не можете витягти цю інформацію з інших інструментів?

• Над чим ти зараз працюєш? Квитки я призначив.
• Який ваш прогрес? Для квитків у мене більше 1 дня, дивіться коментарі в квитку або повідомлення про філіали. Квитки у мене коротші: напевно, зроблено завтра (ви не робите великих 5-денних квитків, так?)
• Який загальний прогрес? див. співвідношення відкритих / закритих квитків
• Що потрібно організувати? квитки, які вам присвоєні, із необхідним зворотним зв'язком зі статусом , і все, що обговорюється в IRC вашої команди, кімната для багаття, що завгодно.

Коли у вас є більш конкретні запитання, на які потрібно відповісти, я б побачив необхідність у конкретних звітах, але без цього ваші звіти виглядають трохи як самоціль.