Як ви відстежуєте, що ви та ваша команда працюєте щодня?

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

Я думав про те, щоб запровадити якийсь щоденний запис, який всі заповнюють (через список розсилки або спільний доступ до google doc), але це здається досить громіздким та посібником.

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

Які стратегії ви реалізували, щоб бути в курсі того, що робить ваша команда щодня, щоб можна було виміряти роботу над "незавершеними" завданнями?

Я з ними розмовляю.

Технологія не може вирішити соціальні проблеми. У вас короткі ранкові стадії. Що ти робив вчора? Що ви будете робити сьогодні? Якісь перешкоди?

Якщо щось звучить рибливо (або мені цікаво), я зупиняюся і задаю питання: "Ви працювали над XYZ вчора, як це вийшло?". Це змушує людей звертати увагу і насправді знати, що відбувається. Це також утримує вас, що команда веде себе у циклі (і звертає увагу, і знаючи насправді, що відбувається). Це потрібно вчасно та коротко ( максимум 10 хвилин ). Все, що завгодно, і люди не будуть "стелати" роботу. Вони зупиняться і чекатимуть очікування, а потім знадобиться час, щоб почати знову. Деякі це робитимуть у будь-якому разі, але це в значній мірі неминуче.

Тоді я вдень заїжджаю за парти всіх. Не кожного дня (хоча для нових людей це може бути більше, ніж кожного дня), не в один і той же час, але приблизно в один і той же час (тому це і неформально, і регулярно). "Якісь проблеми? Якісь перешкоди?"

Ви здивуєтеся, як часто ви будете стикатися з проблемами, коли люди один на один.

Якщо у людей немає проблем, чудово; повертайся до роботи. Якщо вони не матимуть проблем цілий тиждень ? Проблема. Ви недостатньо кидаєте їм виклик, або вони не відкриваються. Запитайте, як проходить XYZ (про що вони згадували в standup). Змусьте їх пояснювати речі.

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

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

Примітка: Один надзвичайно серйозний бік: наскільки велика ваша команда? Це більше 7 осіб? Звичайно, ви не зможете відслідковувати все, що відбувається, якщо ваша команда занадто велика.

Не мікро-керуйте своїми розробниками!

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

Як пропонує Роберт Харві , не керуйте мікрою командою. Дайте команді кілька пріоритетних завдань, що мають конкретну ділову цінність, і дозвольте вашій команді якнайкраще розібратися, як досягти цінного бізнесу.

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

Однак:

Картки залишатимуться впродовж днів без оновлення під час щоденного очікування

Це може означати, що в процесі є дефіцит.

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

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

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

Але дайте команді з’ясувати, чи є проблема, і в чому причина. І будьте готові визнати, що, можливо, вам потрібно відрегулювати спосіб передачі завдань команді.

Пам’ятайте, що щоденне вставання є інструментом для команди, яка допоможе їм організувати роботу; це НЕ інструмент для менеджерів, щоб слідкувати за тим, що робить команда.

"Push messaging" не "тягнути повідомлення"

Розробник часто потрапляє до одного з наступних важливих для вас станів:

1. Yaaay, я зробив X!
2. Я працюю над X, але, схоже, це займе тривалий час ...
3. Я застряг у проблемі Y, досліджую її, але, можливо, знадобиться порада;
4. Мене заблоковано, тому що я чекаю A, B і C.

В ідеалі ви хочете мати досить актуальну інформацію про ці статуси, не порушуючи фактичної продуктивності. Постійний "Ми там ще?" є контрпродуктивним, але, можливо, ви можете зробити щось корисне для станів 2-4, тому вам потрібно про них поінформувати.

Що буде працювати - це культура "передачі повідомлень", бажано в автоматизованому вигляді. Можливо, вам не потрібно буде дивитися на весь журнал комісій, але ви можете зробити "інформаційну панель", де ви бачите останню фіксацію або останній вирішений квиток (для помилок або функцій) кожного члена команди. У решті ситуацій ви можете змусити їх надсилати електронне повідомлення електронною поштою з такими оновленнями (сподіваємось, вони рідше, ніж коміти), або перейти і запитати їх, якщо ви не бачите постійного прогресу на будь-якій інформаційній панелі - якщо у вас є Внутрішня згода про те, що застрягання потрібно підвищити (можливо, якась функція не потрібна, якщо виявиться, що це коштує 80 годин, а не 8 годин), то або вони будуть постійно тримати вас у курсі, або вас турбуватимуть.

Крім того, ви можете створити культуру на зразок https://idonethis.com/ щоденних звітів, що надходять до всієї команди - це гарантуватиме, що інші також будуть на одній сторінці.

Альтернативою деяким іншим відповідям (орієнтованим на спілкування) є те, що, можливо, завдання на ваших нотатках можуть бути розбиті на більш дрібні шматочки, про які ви зможете отримати зворотній зв'язок швидше.

З меншими шматками команда відчуває, що вони щодня роблять щось, що має відображатись у складі рейтингу.

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

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

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

Я пропоную це, тому що я працюю в команді з 8 осіб, де спілкування дуже просте, а люди дуже доступні. Нам дають завдання, які ніколи не повинні зайняти більше ніж два дні роботи. Іноді ці завдання тісно пов’язані між собою, і нам потрібно постійно інформувати одне одного про те, як ми працюємо над власним твором. Ми несемо відповідальність за те, щоб повідомити менеджеру про те, що ми виконували кожні два тижні.

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

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

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

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

Тепер припустимо, що ви просто менеджер, як я вже говорив вище, в такому випадку, навіть якщо якийсь розробник справді стикається з якоюсь серйозною проблемою, пов’язаною з розвитком, ви, можливо, не зможете допомогти їй / йому. Актуальна проблема може зайняти багато часу і вимагатиме концентрації. Далі припускаючи, що розробник справді щирий за свою роботу і приділяє повний робочий день (навіть додатковий час) для вирішення цієї проблеми, але, на жаль, все ще не в змозі її вирішити. І в такій ситуації (коли ви навіть не в змозі зрозуміти проблему повною мірою), ви постійно запитуєте про це, роблячи прогрес щодня і навіть неофіційно двічі на день. Результатом було б надзвичайне розчарування та занепокоєння для забудовника. Незалежно від того, чи це додаток для збирання щоденного прогресу, чи просто щоденна зустріч з резервним станом, це може бути розчаровуючим.

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

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

Створіть та добре використовуйте різноманітні чати для чатів для різних конфігурацій. Деякі можуть бути широкими, як @engineers, а деякі можуть бути конкретними, наприклад @newFeatureA

Розгляньте можливість щоденного резервного огляду включати огляд квитків у польоті.

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

Як зазначає Роберт, перш за все, не слід вважати мікроуправлінням (зверніть увагу на використання "бачити", тобто незалежно від вашого фактичного наміру).

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

Я здивований, що тут ніхто ще не згадував повідомлення "схожих" або "зіркових" репозиторій, вбудованих у такі системи, як GitHub або BitBucket.

Наші технічні зацікавлені сторони (керівники проектів, менеджери з розробки та підтримки) всі слідкують за нашим питанням та проводять історію оновлення відповідних проектів. У нас є невелика команда (15 FTE + підрядників), але це, здається, працює для нас

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

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

У поєднанні з RSS-каналами, пов’язаними з конкретними сховищами або з усією нашою організацією, ми мали змогу обмежити електронні листи (де потрібно) та запропонувати аналогічний набір даних у режимі реального часу та підсумків за допомогою RSS-зчитувачів. Для деяких користувачів це Outlook, тому в основному вони надсилаються електронною поштою, хоча і дещо відрізняються, але для інших користувачів вони використовують повноцінний RSS-клієнт із усією додатковою фільтрацією, яка їм потрібна, щоб налаштувати його під їхні точні потреби.

Спочатку ми зіткнулися з подібними проблемами щодо обсягу електронної пошти, але наші кінцеві користувачі придумали систему RSS, не маючи на тему Інженерного органу багато чого, крім того, пропонувати клієнтам для тих, хто не використовує Outlook. Працювали для нас, знову близько 20-30 FTE + підрядників протягом року в різних офісах та часових зонах. YMMV, очевидно.

Це дуже маргінальне доповнення (і це не конкретно для програміста), але я успішно працював з Асаною в останніх проектах.

Для інтеграції з існуючими інструментами онлайн-співпраці шукайте не далі, ніж Slack . Він побудований навколо чат-кімнати, але він служить досить мінімалістичним центром для інших інструментів, зокрема Asana, GitHub та Bitbucket. У ній є гідна колекція цих "інтеграцій", як попередньо виготовлених, так і загальнодоступних , використовуючи API, що, звичайно, дозволяє створити власну.