Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Що робити, коли на дейлі-мітингу немає оновлень. Шпаргалка для менеджера та розробника

Привіт, мене звати Северин, більше шести років я працюю в ІТ та близько року в ролі Scrum Master — встиг набратися досвіду і як розробник, і як проєктний менеджер.

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

Стаття розрахована на широке коло читачів, може зацікавити як початківців у менеджменті, так і розробників, тестувальників і людей, які не займаються ІТ.

Ілюстрація Аліни Самолюк

Види мітингів

Щоб відповісти на питання, «як проводити дейлі-мітинги, коли нема оновлень», варто спершу розбити його на блоки. Почнемо з дейлі-мітингів. Що це взагалі таке?

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

Якщо ми говоримо про адаптивне (Agile) середовище, ці мітинги вже є не просто статус-мітингами. Правильніше їх назвати дейлі-синкапами. Тут уже не проєктний менеджер приймає роботу, а команда. Чому саме так? Тому що в Agile-середовищі позиція PM відсторонена від команди розробників/виконавців. Відповідальність за виконання зміщена від PM у бік команди та власника продукту. Саме команда найбільше зацікавлена в тому, щоб робота була зроблена вчасно та якісно. Тому синкап — це синхронізація насамперед колективу.

Розібралися. А тепер перейдімо до оновлень. Тут усе просто: це актуальна інформація щодо виконання завдань.

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

Що таке апдейт

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

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

Ці три питання є сакральними. Вони дають базу для роздумів: чи справді мені немає що сказати на дейлі-синкапі?

Йдемо далі. Що означає «немає апдейтів»? За останню добу чи від останнього мітингу нічого не відбулося на проєкті? Чи немає оновлень, бо не просунувся далі в роботі, або немає що показати, адже ще працюю над завданням? Ось у цьому велика різниця!

Нічого не робив? Тоді в нас проблема. Або менеджмент/команда не дала роботу, або член команди нічого не хотів виконувати. Тут уже треба розбиратися, та загалом це не тема нинішньої публікації.

Задача ще не зроблена? Можливо, не просунувся в роботі, але старався і пробував варіанти? Це теж важливо. Наприклад:

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

Тут висновок такий: будь-яка інформація може бути корисною, якщо на неї глянути під правильним кутом.

А тепер до кейсів

Розгляньмо вищезгадані приклади докладніше.

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

Але також не треба забувати про зворотний зв’язок від розробника/виконавця. Перед виконанням будь-якої задачі необхідно впевнитися, що є мінімум три складники для роботи: чіткі вхідні дані, чітке розуміння результату й термін виконання задачі. В цьому разі треба переконатися, чи розробник розуміє, як виконувати завдання. Якщо так, ставити дедлайн. Якщо ні, варто розбити його на етапи. Можливо, в процесі чергового синкапу комусь спаде на думку ідея розв’язання питання на основі вже готового дослідження.

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

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

Ще один варіант ефективно використовувати час — мати запасні задачі, так звані Stretch Objectives. Тобто якщо ви заблокані або швидко закінчили першочергові таски, щоб не сидіти без діла, беріться до виконання запасних.

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

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

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

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

Шпаргалка для керівника-початківця

Для людини на менеджерській посаді дуже важливо бачити рух, тенденції, здорову робочу атмосферу в команді. А коли ж це побачити як не на дейлі-мітингу? На початку зустрічі зробіть перший крок, задайте тон синкапу. Наприклад, спитайте: «Як ваші справи» або «Чи бачили ви презентацію нового гаджета?». Буквально дві-три хвилини, постарайтеся розговорити людей. Цілком ймовірно, що команда підхопить ініціативу і розмова зав’яжеться, а там і синкап, і подальше обговорення.

Мені на початку менеджерської кар’єри було непросто це зробити — розпочати вдало дейлі, задати правильний тон. Особливо в молодих, ще не сформованих або тимчасових командах. Я старався все контролювати та вести мітинги — одне слово, більше говорив я. Але з часом зрозумів, що команду треба «відпустити» — розігріти та тримати в робочому тонусі, запропонувати місце, де колеги бачитимуть поточний стан справ (наприклад, Kanban-дошка та прості для сприйняття графіки, навіть в Excel), але дати їм свободу — і вони самі себе поведуть. Завдання менеджера — лише модерувати «плавання». Десь читав фразу, що менеджер має говорити менше, ніж команда. Щось у цьому є.

Створіть комфортні умови для співробітників: щоб було почуття впевненості, підтримки з боку колег і простір для професійного розвитку. Тоді команда буде ефективною та самодостатньою.

Висновок

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

Планувати, аналізувати та адаптуватися — це правильний шлях до досягнення успіху. А без ефективної комунікації, особливо на дейлі-синкапах, не буде основи ні для аналізу, ні для адаптації.

Якщо вам цікаво спілкуватись або бажаєте бути в контакті, додавайтесь в LinkedIn або читайте мене на Medium.


Щоби не пропустити нові статті Северина Рибчинського — підписуйтеся на нього у телеграм-боті Стрічки DOU.

LinkedIn

Похожие статьи

Лучшие комментарии пропустить

Все гуд, але от від цього дуже горить:

Відповідальність за виконання зміщена від PM у бік команди та власника продукту

Це ж просто чудово! Якщо все виконано вчасно, скоуп зроблений, релізнулись вдало, то молодець PM, бо він руководив. Якщо все погано, то відповідальність на команді. Дуже зручно :)

"у сємі нянєк дітя бєз глазу«©.
не існує ніякої «командної» відповідальності. якщо у задачі немає призначеного васі пупкіна, який відповідає за її виконання, то задача не буде виконана або буде виконана через жопу.

98 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Получилась коротша сама стаття ніж «стаття» в коментарях)

А як зробити, щоб була "Саме команда найбільше зацікавлена в тому, щоб робота була зроблена вчасно та якісно"?🙂

Що робити, коли на дейлі-мітингу немає оновлень

Розбиратися, що не так з кваліфікацією керівника проекту.

Намагався вирішити, але не вдалося.

А це тому, що задача не повинна була бути поставлена як «намагатися вирішити». Задача повинна бути розділена на дві: розібратися, чи можливо це зробити ось таким шляхом і, власне, зробити. Перша задача не може закінчитися станом «не вдалося» — ми або вияснили, що зробити можливо, або вияснили, що зробити не можливо. Друга задача або не почнеться, або теж завершиться вдало. Розробнику в жодному випадку не доведеться виправдовуватися, що йому щось не вдалося.

Не зробив, бо був заблокований чимось

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

Нема апдейтів, бо ще в роботі.

А це взагалі що? «В роботі» — це взгагалі то кажучи і є апдейт. Якщо задача «в роботі» більше якогось адекватного проміжку часу — задача керівника розбити її на підзадачі.

Не готово через особисті причини тощо

Стаття взагалі якось дивно пояснює, що таке «особисті причини». Особисті причини — це емоційний зрив, депрессія, запій, хвороба тощо. І задача керівника — підставити плече і прикрити, принаймні перші кілька разів. Я не раз бачив, як люди виходили з особистих негараздів при буквально мінімальній допомозі. Звичайно, якщо після кількох спроб нічого не вдалося — може і настати час прощатися з людиною, але це буде ну може в одному випадку з 10.

Але, йой, я ж забув, що

в Agile-середовищі позиція PM відсторонена від команди розробників/виконавців

, тому яка ж тут може бути розмова про кваліфікацію керівника, він же «відсторонений»! Тому живіть з дейлі-мітингами без апдейтів і далі, ага.

Не сарказма ради, но интереса для (вдруг мой опыт был лишь в незрелых командах)

Severyn Rybchynskyy вы не могли бы после «дейли-синкапа» взять произвольного сотрудника и попросить его рассказать про всех остальных членов команды: что они вчера делали, с какими проблемами столкнулись, что сегодня будут делать и какие блокеры.

Десь читав фразу, що менеджер має говорити менше, ніж команда.

ну тоді «менеджер» перетворюється в лідера. в моєму розумінні менеджери роблять мікроменеджери, здорова і зріла команда цього не потрбує. будуть страждати і проект і команда і менеджер.
стенд-апи також корисні не тільки для суто проектних синкапів. як щодо team coherence, як їй не покращуватися як не на стенд апах. дуже важливі речі відбуваютсья на стенд апах — не вербельне спілкування!
бачу багато коментарів виключно про хард складову. але ж стенд ап це не тільки про хард, і скоріше це про софт скіллз.

Ці три питання є сакральними.

(мем з Бороміром)
Не можна просто так взяти і відмовитися від догм і сакралізації.

А не думали, що, може, мітинги зайві, коли на них нема чого доповідати??
(Що не значить, що вони не зайві в іншому випадку)

Добрий день, дякую за коментар! Так, певною мірою Ви праві, але в даній статті, я спробував описати власне дейлі-мітінг, як синкап команди. Тому дейлі синкапи в Командній Роботі(!!) є необхідними і завжди є що сказати(покрайній мірі, точно знаю це зі свого досвіду 6+ років в ІТ). Треба лише підказати в якому напрямку рухатися щоб знайти істину. Дякую

Тому дейлі синкапи в Командній Роботі(!!) є необхідними і завжди є що сказати(покрайній мірі, точно знаю це зі свого досвіду 6+ років в ІТ)

Рекомендую почитати Organizational Patterns of Agile Software Development epdf.pub/...​are-development31531.html

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

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

Дякую за референс, перечитаю! Тут мається на увазі невеликі команди, 6-8 чоловік. Дейлі синкапи виключно раз на день для всієї команди, решта сикнапів за необхідністю і не обов’язково всій команді. + синкапи до 15хвл, але нажаль це вже не тема даної статті. Загалом з Вами цілком погоджуюся, але дана стаття лише про те, що синкапи важливі і що завжди є що сказати)

але дана стаття лише про те, що синкапи важливі і що завжди є що сказати)

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

Себто, коли розробники незалежні, то статус справ одного розробника є інформаційним шумом для усіх інших. Так само, як ви не запрошуєте представниць ХР відділу на свої дейлі стендапи.

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

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

Дейлик как раз для погонщика)
Очевидно что чужие задачи не особенно интересны коллегам по команде. Кому интересно — смотрит в джиру. Кто своей таской заблочил коллегу — отпишется как только закончит.

Процессы они не для рядового сотрудника, а для компании, менеджера, проекта ;-)
Это не плохо и не хорошо. Просто нужно это знать.

Процессы они не для рядового сотрудника, а для компании, менеджера, проекта ;-)
Это не плохо и не хорошо. Просто нужно это знать.

Зависит от целей менеджмента — исходя из них может быть плохо или хорошо.

Например, есть измерение code ownership <-> заменимость сотрудников. Если хочется, чтобы все были легкозаменимы — продуктивность будет в разы ниже, чем когда каждый независимо пилит свой кусок. Зато руководству не надо заморачиваться с удержанием ценных сотрудников. И объем проекта в человеко-часах внушает уважение, а за эти человеко-часы конторе платят.

С другой стороны, процессы могут быть так настроены, что в команде программистов только один человек занимается связями со внешним миром. Его принесли в жертву обстоятельствам, он сидит на поддержке и удовлетворяет пользователей. Может, в следующей жизни станет ПМом. А сейчас — дает возможность остальным спокойно работать, не отвлекаясь. Процесс? Процесс. Сотрудникам жить проще стало? Проще.

Итого, ИМО: разумно настроенные процессы кому-то облегчают жизнь (вероятно, тому, кто их создавал). Иначе — они не разумно настроены. Если у этого человека была цель облегчить жизнь программистам, и он понимал, что делает — есть хороший шанс что процессы реально помогут. Тот же скрам в оригинале защищает программистов от пожара и хотелок «на вчера» — «мы берем новые задачи только в следующий спринт, и работаем со своей velocity». Другое дело, что его сейчас натягивают на и запихивают в куда не нужно.

И не нужно путать популярный нынче недо-скрам с процессами. По процессам как раз хорошая книжка Organizational Patterns of Agile Software Development. Но она не дает серебряной пули — только набор из сотни-двух инструментов, для применения которых нужна голова и полномочия.

И не нужно путать популярный нынче недо-скрам с процессами.

именно

от же скрам в оригинале защищает программистов от пожара и хотелок

вообще-то нет скрум сделан вовсе не для «программистов» и с единственной целью сделать простой коммуникативный фреймворк для реальных синьоров здесь реальных не тех которых продают на галеры а реальный синьор способен сделать проект сам собой своими силами вопрос только в масштабируемости для больших проектов и соотв. «8 реальных синьоров работающих над 1 проектом» и вот им нужен простой и внятный «коммуникационный фреймворк» и именно потому в скруме нет «менеджера» но вместе с тем есть decision point в виде product owner

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

именно ключевое слово «нужна голова» а натягивание скрума на головы простых гребцов есть ничто иное как карго культ со стороны погонщиков просто потому как самим гребцам никакой скрум и не нужен они всё равно им пользоваться не умеют а гребут единственно куда скажут

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

и да именно потому как у «эффективного менеджера» именно «полномочия» а вовсе не общее понимание на уровне с простыми гребцами чтобы лодка плыла ровно и в нужном направлении селяви ничего личного просто бизнес

Дейлик как раз для погонщика)

дейлик как раз для идиота погонщика я уже много раз спрашивал таких № 1 зачем тебе «дейлик» чтобы знать кто что делает если ты и есть ответственное лицо которое должно раздавать и соотв. априори знать кто что делает а если ты не знаешь то зачем ты вообще? № 2 зачем тебе «дейлик» чтобы знать кто что делает если все всё равно всё трекают в джире или какая там трекалка а «технические детали к обсуждению прямо запрещены» причём лично тобой об чём ты каждый раз не устаёшь напоминать на каждом «дейлике» так зачем тебе «дейлик» если просто открыл джиру и сразу видно кто что работает и как долго и вообще?

Кому интересно — смотрит в джиру.

оборжака да? )) простой гребец может посмотреть в джиру чтобы увидеть чужие задачи а погонщику для этого нужен «дейлик» вы (здесь обобщение) там все реально здоровые ли или пора поликлинику вызывать для опытов? ))

ЗЫ: остальное написана ерунда от не понимания процессов и зачем они нужны сорри

завжди є що сказати

Так, завжди є що сказати, завжди можна сказати що робив вчора, що буду робити сьогодні... Але то не завжди цікаво чути іншим членам команди. Якщо заглиблюватись у технічні подробиці, то це може розтянути формально 15-хвилинні синкапи. Тому типовий мітінг виглядає так: «Вчора я працював над (далі йде номер задання в джірі чи його формальний опис), зробив його, сьогодні планую зайнятися (далі теж номер чи опис)...» Але то нікому не цікаво крім менеджера чи скрам-мастера.

А менеджер та скрам мастер могли б подивитись в джирі і не відволікати виконавця.

звучить як «стенд апи» і «скрам мастер» чиста формальність і ніякої командної роботи. ну і звичайно якщо нікому цікаво... різниця між називатися і бути.

Але то не завжди цікаво чути іншим членам команди

 Ну так это им решать? а для этого они должны что то услышать ) Это одна из причин для «говорить». Потому что «молчание» — оно золото, которое уплыло мимо вашего кармана.

Ну так это им решать? а для этого они должны что то услышать )

А может, в первую очередь решать, тратить ли время на то, чтобы слушать?

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

а я про что сказал?

если ютюба нет, то о каком решении вообще может идти речь?

Ты сказал, что надо всем ходить на митинг, чтобы понять, слушать ли митинг.

Я сказал, что если вдруг людям захочется митинг — они соберутся и один раз митинг сделают, когда захотят. А по умолчанию он не нужен.

о, ну это ты так понял ))) я не говорил про

всем ходить на митинг,

нет у меня таких слов

Ну так это им решать? а для этого они должны что то услышать ) Это одна из причин для «говорить».

програміст не має достатньо часу та ментальних ресурсів, щоб заглибитись в код та архітектуру
So true bro🙁
Особенно когда ставят на 10, 13 и 16. День порезан на куски по два часа. Я только час могу входить в сложный контекст

Тут описаний дейлі стендап яким він має бути. Нажаль в багатьох проектах в якіх я був — взагалі не стендап, а відкривають jira бороду і «ганяють» по ній тікети. Потім звіряються по «продук роудмапу» що проект іде за графіком. Якщо в тебе тимчасово нема тікета на борді — можеш спокійно собі промовчати і спитати в керівника собі якийсь, якщо візьмеш тікета сам — чекай на відповідну розмову з керівником. Такі проекти дуже полюбляють всім казати що в них «срам і ажайл» :) 2. «Зайві» мітинги — це інша справа, це трапляеться коли нема агенди і на нараду просто кличуть всіх підряд — і тих хто там потрібен і ні.

Тут посил, чи він взагалі має бути

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

Ви натягаєте срам на глобус.
Скрам не є єдиним можливим робочим процесом.
І в багатьох інших процесах нема групових мітингів та стендапів.

Але з часом зрозумів, що команду треба «відпустити» ...... дати їм свободу — і вони самі себе поведуть.

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

Добрий день, дякую за коментар. Власне тут я описав команду яка працює за аджайл світобаченням. Тобто «рулити» має власне команда, а Скрам Мастер(чи будь хто на менеджерській позиції) має команді пояснювати процеси, підтримувати її та усувати перешкоди. Такий досвід я отримав на декількох проектах. Хоча не всюди це діє/працює в повному обсязі, тому Ви праві — в певних випадках ПМ присутність має бути активною. Дякую!

Ц насправді тут можна чітко зрозуміти різницю між PM & SМ, менеджер то і рулить, але команда тоді і не приймає самостійно рішення, а Аджайл і Скрам, в тому числі, базується на селф органайзд і селф-менеджер командах, де саме команда бере на себе відповідальність за прийняті рішення.

"у сємі нянєк дітя бєз глазу«©.
не існує ніякої «командної» відповідальності. якщо у задачі немає призначеного васі пупкіна, який відповідає за її виконання, то задача не буде виконана або буде виконана через жопу.

А в них там самоорганізація дива творить:

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

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

А тех ліда найняти не пробували?

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

ви зустрічали такі проекти коли кожне індивідуальне завдання виконане, «а воно не їде» все одно?

Це значить, що немає єдиного бачення технічної сторони проекту — замість будинку отримуєте звалище будматеріалів бо кожен ліпить що заманеться куди заманеться. www.laputan.org/mud

Або не маєте єдиного Product Owner, і собаці дошивають 8 ніг щоб швидше бігала en.wikipedia.org/wiki/Design_by_committee

так, і такі пояснення можуть бути. тільки чому ви вирішили зо це СУТО технічна проблема, яка має бути віришена тільки технічними спсобами? чи всі проблеми мають вирішуватися технічно?
як їх виявити якомога раніше і покращити якомога раніше? Більше котнролю і звітів?
Чи може тісніша співпраця? почути в кого які проблеми і зв*язати точки.
не завжди це технічна проблема. дуже часто технічне рішеня просте. і як тільки команда чесно, відкрито і спокійно розповідає в чому саме і де саме проблема, то може вирішити самостійно, і тільки у деяких випадках ескалювати PO.
не з кожною проблемою можна і треба ходити дл РО. на те вона і self managed команда, щоб вирішувати проблеми.

тільки чому ви вирішили зо це СУТО технічна проблема, яка має бути віришена тільки технічними спсобами?

Де я писав, що тут технічна проблема? Тут — проблема керування проектом. А саме керування проектом має три складові: технічну, продуктову та персонал.

як їх виявити якомога раніше і покращити якомога раніше? Більше котнролю і звітів?

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

Чи може тісніша співпраця? почути в кого які проблеми і зв*язати точки.

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

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

Навіщо це кожній окремій людині в команді? Премію дадуть 100% місячної зарплатні? Чи +10 днів до оплачуваної відпустки? А якщо це нікому з працівників не вигідно, то ніхто й не схоче займатись вирішуванням проблем керівництва проекту.

на те вона і self managed команда, щоб вирішувати проблеми.

От вона й вирішує. Вам не подобаються результати? Не довіряєте команді?

Працівник не є зацікавленим в успіху проекта.

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

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

Може, плутаєте причину з наслідком?

на жаль, сучасні технології не значить сучасне чи прогресивне мислення.

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

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

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

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

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

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

мій проект дуже складний і неймовірно нудний. але це не змінює ситуацію. професіонал знайде спосіб самореалізації!!! навіть на такому проекту. мова про персональний інтерест і зацікавленість. професіонал скаже — мене не цікавить цікавий проект чи ні, я знаю куди мені розвиватися і як я можу будь який проект успіхом.

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

Це не сучасне мислення, а втеча від свободи. Почитайте класику modernproblems.org.ru/...​2-begstvo-ot-svobodi.html Коли людина не має індивідуальності, соціально та ментально незахищена, і не має гідної мети власного життя — тоді тікає від невизначеності буття в відчуття спільноти з будь-якою силою, і отримує від цього «відчуття значущості». На цьому базуються націоналізми, серед яких і соціал-націоналізм. І комунізм також з цього росте.

Сучасна мейнстрім філософія відійшла від зникнення особистості в спільному вже років 100 як. Екзистенціалізм — про буття особистості, а не про належність працівника до лав контори. Вже 40 років як навіть мультики про це роблять youtu.be/cAVjKMOkTr8?t=269

мій проект дуже складний і неймовірно нудний. але це не змінює ситуацію. професіонал знайде спосіб самореалізації!!!

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

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

Професіонал каже «мені не цікаво писати на джаваскрипті іграшки, піду займатись розпізнаванням обличчя». Думаєте, він програє хоч за одним параметром?

а втеча від свободи

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

професіоналу думать, як знайти собі спосіб самореалізації на проекті

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

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

Але майже гарантує розвиток вшир (нові технології) та підвищення зарплатні. Чого нема на поточному проекті.

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

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

не має гарної відповіді. це питання віри і майстерності учасників в кожній окремій ситуації.

Ви канбан відносите до agile?

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

є точка зору що канбан це не agile в чистому вигляді, канбан суперечить pull principle.

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

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

От як раз в канбані взагалі нема командної роботи. Хтось закидає задачі на конвейєр, хтось робить, ще хтось — тестує. Усі незалежні.
І ніяких скрам-майстрів чи стендапів. Нафіг усе зайве — і, (як не дивно?), працює.

Що може буть гнучкішим за канбан

Scrum звичайно. Kanban навпаки не гнучкий, є чіткі дати що і коли має бути готово... або ми говоримо про різні речі.

От як раз в канбані взагалі нема командної роботи. Хтось закидає задачі на конвейєр, хтось робить, ще хтось — тестує. Усі незалежні.
І ніяких скрам-майстрів чи стендапів. Нафіг усе зайве — і, (як не дивно?), працює.

це мені нагадує дискусію «що ви робите?» — кладете цеглу чи будуєте Сикстинську капелу.
мова про те, хто що бачить і хоче бачити. Канбан конвеєєр? можливо. але чи це значить що не має місця комунікації і співпраці? і саме головне — чи подобається вам такий стан справ? ви хочете бути роботом? ви хочете працювати 09-00 : 18-00, чи хочете створити щось цікаве?
працює, не питання. кайф після такої роботи є? а скільки ви так протягнете, рік, може 2, а потім нова галера? ну ок. це персональний вибір.

Kanban навпаки не гнучкий, є чіткі дати що і коли має бути готово...

В канбані нема дат. Є лише пріоритизований список задач. Все.

В скрамі є релізи, взаємозамінність людей в команді, різні види мітингів та ролі. Велика бюрократична система. Навіть (нікому не кажіть) критичний баг не можна брати в середині спринта. Якщо прод впав — покладіть задачу в наступний спринт, за два тижні її заплануємо.

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

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

В канбані нема дат.

Really?

Kanban (看板) (signboard or billboard in Japanese) is a scheduling system for lean manufacturing and just-in-time manufacturing (JIT).[2]

Канбан весь крутится навкого запланованого, тобто прив*язоного до конкретного моменту часу в майбутньому виконання завдання.

Ми говоримо про свої досвіди, не обов*язково як має бути.

Можна тут почитать dzone.com/...​n-scrum-vs-kanban-vs-lean
або тут en.wikipedia.org/...​wiki/Kanban_(development

Ваша помилка у фразі

запланованого, тобто прив*язоного до конкретного моменту часу в майбутньому

Заплановане — це покладене в чергу з пріоритетами між двома задачами: більш важливою та менш важливою.

Так, давайте в семантику значення, schedule. Ой, а там як раз про час, а не про пріоритети.
Я маю на увазі будь кий Канзас, і він як раз може мати due dates, в залежності від потреб проекту, не тільки софтовий.

Я маю на увазі будь кий Канзас, і він як раз може мати due dates, в залежності від потреб проекту, не тільки софтовий.

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

Вот цитирую оттуда:

In contrast to Scrum, Kanban systems, being flow centric, take away the pressure of the Sprint date. The question is: should teams that are used to Due Dates, consider using them on the cards/work items on their Kanban board?

In summary, we need balance! Agile teams advocated against Due Dates because they tend to drive wrong behavior and subvert quality. On the other hand, an absence of Due Dates can lead some teams’ throughput to drop. While estimates driven Due Dates can work well, Kanban systems provide additional help to teams to determine more realistic Due Dates. My recommendation to such teams is to use Due Dates with Kanban cards but ONLY as a guideline — not as something that will make the team compromise product quality and add to technical debt.

I would like to hear about your experience with the use of Due Dates in Kanban systems.

Итого: чувак пишет, что в канбане нет due dates, предлагает их ввести как дополнение, и спрашивает, делал ли кто-то подобное у себя на проекте.

Или я что-то прочел не так в статье?

ЗЫ А еще он пишет, что многие сбегают из скрама в канбан

Fixed delivery date
The second most important Kanban class of service is dedicated to assignments with a fixed date and a high cost of failing to deliver on time. An example of such an item would be preparing an MVP (minimum viable product) by June 6 that comes with a clause, which allows your customer to pay a lower price if you fail to do so.

Projects that qualify for this class require detailed forecasting and careful consideration before committing. We advise you to implement techniques such as Monte Carlo simulations in the process of negotiating the delivery date. They will allow you to run many random simulations based on previous performance to give you probable delivery time frames to minimize the risk of failing to deliver on time.

Бачили щоб хтось робив монте-карло для вибору дати деліварі?
Чи хочете порушити власну документацію, і виставити її вручну?

ви забуваєте що Канбан/Agile/Scrum можуть адаптувати команди із інших видів бізнесу.
наприк. вони вже можуть мати фіксовані дати і вибрали Канбан як свій спосіб ведення проекту.

т.ч. в Канбані (не тільки софт проекти) Можуть бути фіксовані дати

наприк. вони вже можуть мати фіксовані дати і вибрали Канбан як свій спосіб ведення проекту.

А чому вони його тоді обрали?

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

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

А чому вони його тоді обрали?

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

Канбан потребує, щоб керівник проекту вручну слідкував за ситуацією й міняв пріоритети

трохи якось спрощено... є Канбан борд, можливо із датами, можливо ні, і візуалізація!! як раз для того щоб команда бачила і розуміла пріорітети і порядок виконання. Звичайно скрам-мастер має задавати правильні питання, і можливо керівник періодично. Але точно не має потреби постійно перетрушувати всі плани. Команда несе відповідальність і може і повинна відкрито говорити про прогрес. Перекладати чи очікувати все від менеджера..., ну а яка тоді різниця із ватерфолом, де всі ріпортять менеджеру і він приймає рішення. Перевага Канбану це візуалізація і структура для того щоб Допомогти команді виконати роботу.

Сказати що Скрам vs Канбан щось краще..., все залежить від конкретного проекту. Не має універсальної відповіді.

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

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

Коли людина обирає ходить по граблях, чи закручувати шурупи молотком — вона вільна таке робить. Але ж в ІТ бізнес платить цим людям гроші. А люди обирають інструменти, неефективні для задач бізнеса. В результаті бізнес програє. А люди собі інший бізнес знайдуть, коли цей збанкрутіє.

і візуалізація!! як раз для того щоб команда бачила і розуміла пріорітети і порядок виконання.

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

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

В Канбані нема скрам мастера! І ПМ має розуміти, що відбувається, та керувати процесом.

Перекладати чи очікувати все від менеджера..., ну а яка тоді різниця із ватерфолом, де всі ріпортять менеджеру і він приймає рішення.

В вотерфолі менеджер не може нічого змінити, коли вже була розроблена проектна документація. Повільний фідбек. Тому класичний вотерфол не є гнучким методом. В канбані можна змінити наступну задачу для виконання в будь-який момент. Тому Канбан є гнучким. Я маю Вам це розповідати?

Перевага Канбану це візуалізація і структура для того щоб Допомогти команді виконати роботу.

фігня.

А люди обирають інструменти, неефективні для задач бізнеса.

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

Команді пофіг

говоріть про себе:))

Канбан простий

Канбан не такий простий як може здатися. Канбан перебачає continuous improvement, тобто треба аналіз і постійно вдосконалюватися.

В Канбані нема скрам мастера!

Чудово))) Приїхали))) В Канбані не має формальних ролей, але це не значить що команда не може собі вибрати скрам мастера-роль. Як раз навпаки, що не заборонено, то дозволено! це може бути і окрема людина, і менеджер, і може не формально називатися agile coach, agile mentor — як самі собі придумають.

В вотерфолі менеджер не може нічого змінити,

та ладно, scope change control in PMI, нє?

занадто вузький погляд із персонального досвіду, набагато більше можливостей)) не сумуйте))

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

З того, що у Вас ПМ не хоче керувати проектом вручну та відслідковувати де що не втигає зробитись. Такий ПМ завалить Канбан разом з проектом та бізнесом.

Чудово))) Приїхали))) В Канбані не має формальних ролей, але це не значить що команда не може собі вибрати скрам мастера-роль. Як раз навпаки, що не заборонено, то дозволено! це може бути і окрема людина, і менеджер, і може не формально називатися agile coach, agile mentor — як самі собі придумають.

А не соромно, що термін «скрам-мастер» трохи з іншої методології? І що ж він має робить в Канбані? І за що йому мають гроші платить?

та ладно, scope change control in PMI, нє?

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

не хоче керувати проектом вручну

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

термін «скрам-мастер» трохи з іншої методології?

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

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

scope change control

або навіть закриття проекту. завжди є можливості))

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

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

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

Заведіть собі на проекті найманого гопніка, що буде приходити на пів-ставки й розповідати хлопцям, що треба ефективніше працювати)

дуже догматичні уявлення про ватерфол. якщо є нові дані, то або зміна через
scope change control
або навіть закриття проекту. завжди є можливості))

scope change не допоможе з кривою архітектурою (догматичне уявлення про архітектуру?), переробляти архітектуру вже пізно (на ній увесь код написаний), а закриття проекту дуже важко назвати успіхом.

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

легальна причина — це cost of delay і можливо деякі інші.

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

коли ви пояснювали керівництву що саме не працює із такого «скраму», до чого ви домовилися? яка була реакція?

Зазвичай простіше знайти новий проект з ліпшою зарплатнею, ніж щось доводити людині, котра не хоче чути.

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

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

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

тут мені приходить приклад як керівники розвідки США показували Трампу важливі розвідувальні звіти для США. інформація важлива, від цього залежить безпека держави, Трапм не найкращий читач... звичайно вони могли сказати Трамп — м*дак, що було би не далеко від правди і багато хто би їх зрозумів.
і вони знайли вихід. вони знали що Трамп читає коли бачить своє ім*я)) вони почали рандомно вставляти його ім*я, щоб дочитував якомога далі) смішний приклад, але він показує як інформовувач відповідальний за донесення інформації.

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

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

Нафіга? Якщо начальник не вміє слухать — хай вміє рятувать проект, що розвалюється через недочуте.

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

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

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

То чому вважаєте, що комусь має буть цікавим збирать цеглу?

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

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

Як раз останні 6 років робив свій проект, і за це платили, і створювали комфортні умови. Якби не платили, чи були б гірші умови — тоді б шукали когось іншого.

Хто програв?

якщо ви хочете рости професійно, то скоріше за все це соф скілз.

Порівняйте зарплатні тех ліда та тім ліда. Чи ПМа та архітектора. Які скіли більше цінують на ринку?

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

Поїдьте на Троєщину, поматюкайте гопників. Після виходу з лікарні — повторіть.

цінуюють, тільки на одних хард далеко не заїдеш, треба і софт.

Заїдеш. А на одних софт — сусідня тема)

Може в умовах укр галер мабуть так.

Може в умовах укр галер мабуть так.

В конторах, де треба робить роботу, а не водить руками, так.

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

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

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

Перекладіть з менеджерської на людську мову

ми як керівники, можемо досягати результату 2 основними шляхами.
(1) роби, що я сказав, я знаю краще — понвний контроль, не має довіри, люди як ресурси (степлери) фіксовані прогнозовані результати
(2) нам потрібно досягти ось ЦЕ, і визначення як виглядає ціль. Команда біжить і знаходить найбільш креативне рішення, горить бажанням досягти, знаходить щось ну вообше, про що керівник і думат не міг, бо явно він не може більш розумним ніж 5 чоловік. всі щасливі, керівник має результат, команда челендж, навчилися чомусь новому, вирішили складне завдання. замовник вражений результатами.
але (2) тільки можливий на здорових і безпечних довірливих відносинах. а це час і зусилля.
тому більшість бере (1).

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

Нідерланди різні) Укр робочій культурі не так легко адаптуватися. хоча тут і різного вистачає)

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

Щось складне тут? Чи неочевидне?

але в такій парадигмі немає місця скрам-майстеру! це замах на святе!!111

Це не доречні жарти. У нас ее має скрам мастера. Більше того, я не використовую термін agile, до того що роблю. Не має ніяких догм, коли хочеш зробити правильно по суті. Коли по формі, чистий формалізм, ну ок.

Я знаю випадки коли люди насолоджувалися пилянням гирі, все так класно, відпрацював і пішов, ніяких траблів.
А потім пішов в іншу компанію, бо не сподобалося і т.д. (прямо як кажуть тут)))
Пішов, спробував справжню self-managed team і став скрам мастером. Ой.
Ви порівнюєте «скрам мастера» і справжнього скрам мастера, і можливо не маєте гарної практики із справжнім досвідом.

Це все можливо, це як раз сценарій контролю, такої собі фабрики чи галери. Ніхто нікому нічого не винен, просидів 8 год, видав коє який результат, вийшов і забув. 20$ підхід, і він працює і найбільше працює.
І коли керівник зрозуміє що його команда може більше, або команда запропонує, чого ми топчимося на місці, або ситуація критичності ресурсів, краще за ті ж гроші, тоді вже просто 20$ не підходить. Треба іти far&beyond, тобто відкривати весь потенціал, креатив і викладатися на повну (ні, не овертайм). Тоді треба давати простір, менеджер має дати команді можливість показати все що вони можуть. Пиляти гирю вже не достатньо. В чому added value?
Мій досвід показує що команди працюють для всіх краще коли мають простір для дій і креативу, коли можуть ефективно впливати. Ефективність на порядок вище. Звичайно є бажаючі пиляти гирю. Для них простий вибір, те що їх влаштовує.

Все гуд, але от від цього дуже горить:

Відповідальність за виконання зміщена від PM у бік команди та власника продукту

Це ж просто чудово! Якщо все виконано вчасно, скоуп зроблений, релізнулись вдало, то молодець PM, бо він руководив. Якщо все погано, то відповідальність на команді. Дуже зручно :)

Відразу видно людину, яка ніколи не працювала в продуктовій компанії.

Подписаться на комментарии