🔥Як тимліду рухати вперед командні задачі?

Потребую ваших порад. UPD: говоримо про квартальні, командні цілі

1. Як формуються цілі у ваших командах?

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

3. Як загалом ви доносите необхідність виконання саме цих цілей та мотивуєте команду на їх своєчасне виконання?

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

Буду вдячний якщо поділитеся своїми порадами чи якимись best practices.

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Андрію, а які саме цілі вас цікавлять? Бувають цілі на спрінт (банальний спрінт гоал), бувають персональні цілі на перформанс ревью, бувають цілі на команду на квартал, наприклад. Які це цілі в вашому випадку?

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

У нашому випадку мова про командні, квартальні цілі. Дякую за уточнення.
Так, компанія має стратегічні цілі і квартальні також. Так, використовуємо методологію OKR.
Ось наприклад: ціль кварталу, виростити LTV на 20%

OKR, LTV, бла-бла-бла... Так треба зразу писати: ми ПРОДУКТОВА компанія.
Цілі команди оутстаферів/оутсорсерів можуть суттєво відрізнятись і ставить їх product owner замовника, ви скоріше скоуп погоджуєте. Користучись аджайл термінологією, у вас є кілька епіків на квартал та й усе. Ну і якийсь «паралельний» процес по цілям команди всередині компанії, якщо компанія достатньо велика і цим переймається (причому це скоріше персональні цілі по кожному члені команди ніж по команді загалом).

Цілі команди оутстаферів/оутсорсерів можуть суттєво відрізнятись і ставить їх product owner замовника

— звісно можуть, а можуть і не відрізнятись) чому

product owner замовника

не може поставити у ціль LTV?)

В аустафі та аутсорсі виникають деякі інші проблеми, бо там у робітника два начальства зі своїми інтересами кожен (аутсорс компанія та замовник).

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

Це трохи описано отут en.wikipedia.org/...​ultiple_principal_problem

До мене дійшло.

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

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

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

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

Чому так відбувається? Навіщо ріжуть ініціативу?

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

Є команди, які по духу — як баскетбольна команда:
А є команди, які по духу — як кружок вишивання хрестиком

То яке рішення, звільняти/наймати поки не буде «правильна» команда?

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

Тільки тобі як ліду щось та й треба вишити, тому мотивувати прийдеться)

То яке рішення, звільняти/наймати поки не буде «правильна» команда?

Ні, просто трохи адаптувати очікування під реальність.
Наприклад, я ніяк не стану Мессі, навіть якщо мене дуже сильно мотивувати.

Проте не потрібно ставати Мессі щоб виграти чемпіонат)

І як давно дворова команда вигравала чемпіонат Європи? Чи ви про «чемпіонат нашого двору»? ))

Чому ви вирішили що вона «дворова»?))

Цікаве порівняння)

А компанія погони дала тренінг не дала?

Не все у світі ідеально) Всі ростуть, всі навчаються)
Розкажіть про ваш досвід будь ласка

1. Як формуються цілі у ваших командах?

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

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

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

На цей момент у нас є домовленість, що 80% зусиль команди будуть іти на бізнес задачі, а 20% на технічні. Звідси й формуємо скоуп спринта.

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

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

3. Як загалом ви доносите необхідність виконання саме цих цілей та мотивуєте команду на їх своєчасне виконання?

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

Техлід це ж не тім лід
Тоді ще менеджер має бути

Євгене, дуже розгорнуто і класно все описали! Дуже дякую, прям занурився у ваш процес)

Як тимліду рухати вперед командні задачі?

Це приблизно як запитати, а як ви пишете програми.

Щоб розписати по суті тут буде кілька статей, краще загугли software tech lead, engineering manager books, podcasts. Там буде і як команду мотивувавти, планування, менеджмент ризиків.

Всі проекти різні, усі люди різні, завжди є якась специфіка)

В загальному, завдання ліда
1. Допомогти сформувати ціль для РО чи бізнесу (типу «дозволити юзати промокоди»), ставлячи кучу уточнюючих питань.
2. Роздробити цю більшу ціль команди на багато підцілей для людини/кількох людей (типу «зробити фронт, бекенд, тести, релізнути»)
3. Зробити план базуючись на естімейтах від команди коли підцілі будуть зроблені. Добавити буфер, сказати РО/бізнесу коди ціль ± буде зроблена.
4. Трекати прогрес, якщо команда відстає віл плану то спробувати підігнати команду. Якщо не виходить, то повідомити РО/бізнес.

Всі проекти різні, усі люди різні, завжди є якась специфіка)

— вірно, тому запитання так і побудовано, як це у вас?)

А як це роблять у Netflix? ©
Нафіга вам опис процесів які дуже залежать від проекту/команди і т.д. ?

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

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

Успішними стають проекти, де задачі атомарні та максимально зрозумілі.

1) Трейдофф — час на виконання проти час на підготовку задачі. Якщо такого вже немає, то у бізнеса скоріше за все будуть з цим проблеми. І крайнім буде ТЛ/ПМ, який «розвів бюрократію і заважає розвиватись»
2) Є чималий ризик спіймати дизморал сеньйорам, які відчувають себе «маленькими гвинтиками». Як результат втратити людей, які тягнуть проект. (Був в такій ситуації. Закінчилось тим, що на проект взяли людину, яка слідкувала за ретеншеном і ротацією)

Кожен учасник проекта має бачити свій скоуп хоча б на тиждень роботи плюс 30% закладати потрібно завищених очікувань в кожен скоуп.

Трохи не ясно куди саме ті 30% йдуть. Це типу задач на 5 днів + 0.3*5 (1.5) дня, чому не на 5 чи 10 днів? Чи це на тиджень накидати 30% більше ніж людина може зробити, щоб працівник вигорів від навантаження і спіймав дизморал, що не встигає постійно?
В цілому дуже мало команд здатні давати норм результат за тиждень, не на початкових стадіях проекту, тому зазвичай планують на 2 тижні.

І найголовніше:
На яке з питань ТСа відповідають ваші поради?

Богдане, ціль будь якого проекта в нашій сфері — це вчасний делівері в межах бюджета. Я не керую великими тімами. Тому не можу давати поради, а лише виказати свою думку. За десятки років роботи я стільки раз спостерігала за розробниками, і стільки раз перероблювала те, що ними зроблено, через те, що вони неправильно розуміли ціль, що можу стверджувати, що всі ці романтичні цілі цікаві допоки не почнеться розпродаж бурбону на розетці. Якщо Ви працюєте за спринтами в 2 тижні — вітаю — Ви в добре профінансованому стартапі, або в продукті, який триває більше ніж пів року або біля того. Знаєте приказку? 95% громадян України живуть в стресі. Інші 5 — в Одесі. Ось Ви саме в Одесі. Інші на аут-сорсі -стафі.

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

Делегуйте биття задач "маленьким гвинтикам

Не ображайте більші шестерні своєю неосвіченістґ і змащуйте ввесь механізм

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

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

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

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

30% додавайте не очікуючи, що їх виконають

Чому 30%? А не перетворяться вони з часом на 50% Думаю, додавання буферів про запас — це слизька доріжка.

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

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

2. Знову ж таки, цілі всередині команди зазвичай мають слугувати як продовження цілей бізнесу / продакту (окрім як ви маленький стартап і дев тіма то і є вся компанія). Тому головне, на мою думку — прозоро комунікувати стратегічні (та й інші) задачі зовні команди і на основі їх формувати цілі команди, аля «як ми команда Х можемо допомогти компанії досягнути цілі Y». Люди, звісно, завжди більше люблять робити те що їм цікаво, і якщо це радикально протилежне цілям компанії — діла не буде. Але то вже проблема хайрінгу чи resource allocation, яку ви маєте просто адресувати потрібним людям.

3. Мотивація у кожної людини внутрішня, я особисто не вірю в те що людину можна «замотивувати» зовні. У більшості мотивація проста — робити те що подобається і отримувати за це найбільші можливі гроші. От наскільки близькі до цього умови ви зможете створити для своїх співробітників, настільки вони і будуть вмотивовані :) Також можна пробувати матчити внутрішні цілі конкретної людини з її задачами, але це вже якщо є час та бажання.

Моя головна порада — сприймайте свою команду як дорослих адекватних людей, які розуміють що таке бізнес і як він працює. І памʼятайте що кінцева мета будь-якого бізнесу — це прибуток, тож всі цілі мають бути так чи інакше направлені на це, просто ви як інженер маєте іншу перспективу ніж, наприклад, маркетолог (на вас покладена задача тримати продукт scalable, maintainable, secure, performant, functionally adequate і цілі мають бути відповідні).

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

Костянтине, дякую за поради! Підкажіть будь ласка, як у вашій компанії і команді працює процес роботи з цілями?

Особисті цілі виявляються і підтримуються піпл менеджерами, зараз я таким не є, але коли був — то «все як у всіх», тобто регулярні 1-1, прозора комунікація, відповідність компенсації та її зростання до зростання співробітника. Бізнес цілі — трохи по-іншому, тут є рівні. Спочатку С-левел визначає стратегію компанію у принципі і трохи деталізує її на кілька років, здебільшого по бізнес метрикам. Потім CTO / CPO / VPoE працюють на тим, як реалізувати ці плани доступними ресурсами (груба кажучи дуже високорівнева пріоритезація продуктів і фічей). Це вже планування десь в горизонті півроку. Потім є процес крос-командного планування на квартал де вже конкретні (втім все ще великі) фічі оцінюються і планується делівері окремих компонентів різними командами. Потім це ще деталізується і робиться чекпоінт вже всередині команд кожні 6 тижнів. Ну і кожен спрінт є ревʼю мітинг де трекається прогрес зовні, і ретро для того самого всередині.

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

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

також людина відкривається.

реакція людей запалювати і затюкати ))

таке відчуття що на ДОУ залишились не зрілі тінейджери 🤡

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

На випадок якщо не хочеться казати в компанії, то можна запропонувати найм і самому 💰 платити

не приємно але такий він вже досвід

Автор,а сами як працює те?

Формуємо всередині команди орієнтуючись на мету бізнесу

+

1. Як формуються цілі у ваших командах?

На основі драйверів (Класно пояснив, правда?)

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

Ті що відповідають цілям та пріоритетам бізнесу (Ще одне круте пояснення, правда?)

3. Як загалом ви доносите необхідність виконання саме цих цілей та мотивуєте команду на їх своєчасне виконання?

А от далі менше жартів і більше практики:
Які ще цілі окрім поставлених можуть виконуватись?
Мотивації є лише 2: морковка спереду, морковка ззаду. Тобто треба піднімати ЗП тим хто класно працює, звільняти тих хто не працює (тут є купа деталей на цілу купу книг та статей).

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

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

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

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

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

Volodymyr, радий побачити знайоме обличчя через стільки часу.
В моєму досвіді працювало все і не працювало все, залежно від контексту. З контекстом, який дав ТС, ти можеш дати кращі поради? Озвуч.

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

На основі драйверів (Класно пояснив, правда?)

— яких?

Ті що відповідають цілям та пріоритетам бізнесу (Ще одне круте пояснення, правда?)

— чому так вважаєте? Чому не ті що подобаються команді?)

морковка ззаду

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

Потім прийде розуміння, які проблеми він не вирішує

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

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

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

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