Як керувати продуктовими командами без насильства

Привіт! Мене звати Богдан, і я продакт-менеджер у компанії Ring, де працюю над R&D нових технологій, що стануть фундаментом для smart home та security пристроїв майбутнього.

За останні роки в мене була низка ролей і пов’язаних з ними цілей. Але так чи інакше всі вони були дотичні до продукту. Я створював хардверні та софтверні продукти з нуля, бачив, як вони зростають, залучаючи тисячі користувачів і доларів США. Будував усередині компанії продуктові команди, спрямовані на швидкі експерименти та валідацію гіпотез. Справлявся з викликами фандрейзингу, пошуку product-market fit як співзасновник стартапу.

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

У цій статті повернемось до базових принципів командного менеджменту і розберемося, як керувати колегами по цеху ненасильницьким способом. Матеріал буде корисний не лише продактам, а й усім, хто так чи інакше керує командами. Не так важливо, що написано у графі «what I do» у вашому Slack-профілі. Головне, що ви хочете стати кращим менеджером.

Чому важливо йти ненасильницьким шляхом

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

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





Майже 100% історій Кремнієвої долини — це нарис про командну співпрацю та ефективний менеджмент, а вже потім описи плодів їхньої праці.

Тож почнімо.

Окресліть своє середовище

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

Apple — одна з небагатьох BigTech компаній, яка організована за функціональним типом. Microsoft, Amazon, Google мають окремі підрозділи та продукти

Ізольовані продуктові команди існують у компаніях, які організовані за функціональним типом (Engineering, Product, Design). Комунікація відбувається переважно на рівні менеджерів функцій, продукт створюють у стилі waterfall шляхом постійної передачі результатів роботи від однієї функції до іншої. Коротше, у вас ширша взаємодія, але вона є менш тісною.

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

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

Що можна зробити вже сьогодні

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

З мого досвіду, в ізольованих командах найважливіше — це взаєморозуміння щодо продуктових цілей та їхньої суті; у виділених — налагоджений процес роботи над продуктом/цілями. За час роботи в Ring я постійно перебуваю в межах своєї ізольованої команди Product & Design. Більшість компаній, де я працював, були стартапами на ранній стадії з виділеними командами. Там співпраця з колегами завжди була тісною. Тож результати прямо залежали від мого вміння організувати процес і того, як швидко я прибираю перешкоди у роботі окремих членів команди.

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

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

В ізольованих командах ви не маєте влади над процесом, тому варто сконцентруватись на глибині комунікації зі спеціалістами з іншої команди, які працюють з вами в цей момент. Це досягається тією ж проактивністю. Наприклад, коли я починаю працювати з новою людиною, завжди організовую 30-хвилинну зустріч чи дзвінок, на якому ми ближче знайомимося. Це допомагає потім під час обговорення ключових рішень. Також заведіть собі звичку проводити регулярні зібрання з усіма командами, дотичними до проєкту. Це дає змогу виявити маленькі проблеми раніше, аніж вони стануть великими. У виділених командах глибина комунікації досягалась органічно. В ізольованих немає такої розкоші. Тож слово і частота його вживання — це ті 20%, які дають 80% результату.

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

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

Наймайте людей в команду правильно

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

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

Кілька хороших книг щодо найму в продуктові (і не тільки) команди

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

— Розкажіть про ваші обов’язки на позиції PM’a в компанії Х.

— Я писав вимоги до продукту.

— Як ви це робили?

— В Google Docs.

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

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

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

Тож розберімося разом, як ефективно побудувати співбесіду.

Що зробити вже сьогодні

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

Підготуйте список запитань, якими вдасться це перевірити за моделлю S-T-A-R(L) (Situation, Task, Action, Result, Learning). Наперед визначте сигнали, за якими оцінюватимете чесноти людини, що формують такі компетенції. Наприклад, для компетенції «Ефективний командний менеджмент» такий сигнал може полягати у тому, як кандидат балансує між «я» та «ми», коли розповідає про свої досягнення.

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

Приклад мого шаблону підготовки до співбесіди на позицію продакт-менеджера


База питань для співбесіди

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

Здобувайте підтримку та формуйте рапорт

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

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

Як почати формувати рапорт уже сьогодні

TL;DR: через досвід та впевненість.

Досвід отримують через постійну жагу до знань та ініціативність. Нещодавно приєднались до команди? Запускаєте новий продукт чи функціонал? Продемонструйте інженерам чи дизайнерам своє бажання розібратись у технічній базі продукту. Організуйте knowledge-sharing сесії, ставте багато запитань, докопайтесь до суті — це все допоможе мати якісніші продуктові ідеї пізніше, які швидше знаходитимуть підтримку, оскільки ви наперед продумали взаємозалежності. Загалом проявляйте цікавість до чужої роботи, і люди вам довірятимуть. Як казав Чак Роадс із серіалу Billions: «Найкращий спосіб побудувати стосунки з людиною — це попросити про послугу, а не запропонувати її».

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

Щодо впевненості, то тут складніше. Багато менеджерів страждає від синдрому самозванця. Це й не дивно. Нам часто доводиться відстоювати рішення у сферах, де наші колеги є більш обізнаними. Але в цьому й суть побудови будь-якого продукту: в об’єднанні ідей з різних сфер і виробленні на їхній основі цілісної концепції. В R&D мені доводиться відчувати це постійно. Ми працюємо з технологіями, котрі мало хто наважується використати у споживчій електроніці. Такі проєкти рухають уперед найрозумніші research-інженери, з якими доводилось мати справу. І в схожій команді дуже легко відчути себе зайвим, якщо не усвідомлювати, що ваша роль як менеджера якраз полягає у перевірці аргументації команди на міцність, а не у наданні їй відповідей. Тому я завжди ставлю багато запитань, допомагаючи колегам докопатись до істини та зрозуміти кінцеву мету. Це дає змогу не тільки значно пришвидшити мій навчальний цикл, а й колегам поглянути на проблему під іншим кутом.

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

Заохочуйте відкриту комунікацію

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

Що зробити вже сьогодні

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

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

Приклад матриці

3. Декомпозувати глобальну ціль продукту на менші в контексті кожної дотичної сфери. Хорошим інструментом для цього стане система OKR’ів. Так зможете визначити ціль для кожної сфери та ключові метрики успіху/невдачі. Це потрібно, оскільки самої матриці відповідальності недостатньо. Усі мають усвідомлювати різницю між успіхом і провалом, і якомога більше бути зосередженими на першому. Зазвичай це залежить від контексту та цілей, які стоять перед командою.


4. Коли створили фундамент, навчайте людей правильно комунікувати, давати зворотний зв’язок і висловлювати свої розчарування. Гарним ресурсом, щоб зрозуміти, як вести комунікацію, є книга «Ненасильницька комунікація» психолога Маршалла Розенберга. Нижче наведено фреймворк того, як ефективно висловлювати свої розчарування чи давати фідбек колегам.

Фреймворк ненасильницької комунікації

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

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

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

Як це виправити

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

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

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

Вчіться розуміти інших

Розуміння людей та їхніх учинків — це похідна емоційного інтелекту (EQ). Саме він є головною рисою для будь-якого ефективного менеджера. Більшість досліджень підтверджують, що саме EQ визначає кар’єрний успіх людини, а не IQ. Волтер О’Браєн, в якого IQ дорівнює 197, знає це як ніхто. Насамперед це пов’язано з тим, що більшість досягнень роблять групи людей, а не одинаки. Тож вміння ефективно керувати командами й визначає кінцевий результат.

Фундамент емоційного інтелекту — це психологія. Ви не зможете керувати командами, якщо не розумітимете, як провести причинно-наслідковий зв’язок між вчинками колеги та його особистісними характеристиками.

Як краще розуміти людей

1. Почніть із себе. Дайте чесну відповідь на запитання «Чи добре я себе знаю?». Нам часто здається, ніби ми знаємо себе: свої сильні та слабкі сторони, риси характеру тощо. Але коли потрібно їх написати на аркуші паперу, починається «ступор». Тож щоб краще себе пізнати, почніть аналізувати особистісні характеристики: життєві емоції, підхід до роботи та соціальний характер.

2. Оберіть відповідні інструменти. На мою думку, найкращим способом аналізу життєвих емоцій є особистісні тести на основі індикатора типів Маєрс—Бріггс (англ. Myers—Briggs Type Indicator) або його сучасний нащадок Big Five Personality Test.


Щодо підходу до роботи, то багато можна почерпнути з PAEI-моделі Іцхака Адізеса:


А наш соціальний характер визначають стилі прив’язаності (англ. Attachment Styles).

Важлива ремарка! Сприймайте всі ці моделі як можливість структурувати знання про себе як особистості, а не як істину в останній інстанції. Якщо виявили, що рівень інтровертності 90%, це не означає, що ви не можете добре продавати свої ідеї. Це швидше свідчить про те, що потрібно буде докладати більше зусиль. На адресу цих інструментів є багато конструктивної критики з боку експериментальних психологів, але одне можна сказати напевне — це найкраще з того, що ми маємо сьогодні.

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

Підсумок

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

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

На моєму шляху траплялись різні менеджери. Але найбільше допомогли погані. Коли в тебе поганий менеджер, ти розумієш, як робити не варто. Однак саме лише розуміння не створить дорожньої карти, як стати хорошим керівником.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному9
LinkedIn



36 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Я створював хардверні та софтверні продукти з нуля, ...

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

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

А з коментарів видно що більшість читачів це особливо і не турбує :(

Дякую! Чудова стаття!
Розкажіть, будь ласка, трохи детальніше як ви застововували теорію MBTI в команді? Ви застосовуєте цю практику інтуїтивно чи знайомите з нею команду? Цікаво дуже дізнатися, про практичне застосування!
Наперед дякую!

Дякую! Радий, що було корисно! Якогось документованого процесу поки-що немає, але ідеї по тому як це накласти на концепт меритократії. Поки все більш інтуїтивно на рівні відчуттів)

Добра стаття!

На тему краще розуміти людей мені більш сподобалось Kegan’s Theory of Adult Development. Там глибше ідуть порівняльні аналогії чим в Myers—Briggs і пояснюється на якому з етапів розвитку знаходиться та чи інша людина. Тема більш для менеджерів людей, але досить корисно для тих хто росте далі по кар’єрі medium.com/...​-development-d63f4311b553

Ще було б корисним включити Growth Hacking, так як тема достатньо обширна. Andrew Chen на цю тему багато понаписував andrewchen.co. Або ще Elad Gil growth.eladgil.com

Ще цікава тема Product Strategy goodbadstrategy.com

Щоб не спамив ссилками ось нещодавно вже назбирали www.notion.so/...​3d3f346b99d9ff1edb97417b8

Андрію, дякую за посилання! Перегляну.

Продуктова розробка — то круто для бізнесу, коли у тімці всі мінімум мідли. Для новачків — то комфортне болото допоки є продукт і знижнене навантаження по ЗП. Але без регулярного пенделя, бо, як правило, у командах вони у своїх ролях одні

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

Богдан, пам’ятаю як у Львові потрапив на твій воркшоп по цій темі, і дуже радий, що ти тепер оформив презентацію у статтю. У той час, ці поради були дуже цінними і домогли в командній роботі. А це вже майже рік, як стараюся використовувати деякі з описаних тут ідей і думок. Найс) Продовжуй ділитися корисною інфою, буду вдячний)

Як керувати продуктовими командами без насильства

www.youtube.com/...​I&feature=youtu.be&t=4661

Більшість українських компаній не вміє наймати людей для побудови продуктів. Крапка.

А ви вмієте? Хто вам про це сказав?

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

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

Посередній спеціаліст принесе більше деструктиву, ніж класний спеціаліст користі.

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

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

Ви бачили Амазон на власні очі?

Якщо ви не помітили, то я працюю в одній з Амазонівських компаній.

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

Дякую за статтю, Богдане! Повно і водночас лаконічно :) А від кількості посилань на джерела прокайфувала — ваша увага до деталей вражає!

Дякую, Анно! Хотів, щоб інформація була максимально цінною, які приділять свій час прочитанню цієї статті :)

Хорошая статья, много правильных тезисов с точки зрения психологии человека и группы людей и их комфортного существования в рабочем окружении (обязательна для прочтения всем сотрудникам относящимся к отделам рекрутинга и управления быта персонала). Но также данная статья весьма вредна для руководителей технических подразделений любого уровня ибо провоцирует их концентрироваться не на свободном течении работы, контролируемых процессах, снижении рисков как людских так и технических, размытию зон ответственности сотрудников и как следствие уменьшении нормы прибыли на условный человеко-час. От себя рекомендую книгу «Проект Феникс» где в художественной форме более детально описано управление на всех уровнях от минимальной продуктовой команды и заканчивая полным процессом предприятия (кстати там тоже менеджер перешел из отдельной продуктовой команды в управление целым ИТ сектором предприятия и только тогда понял насколько он ошибался в своих выводах о управлении персоналом и правилах этого управления).

Хорошая статья с рекомендациями:
* отсеивать кандидатов по софт скиллам
* проводить побольше митингов
* отвлекать программистов расспросами
* оспаривать решения специалистов чтобы развить самоуверенность

Я радий, що ваші упередження дозволили вам побачити дійсну суть 👍🏻

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

Гарна стаття, структуровано і по суті. Три фото вгорі, я так розумію це відсил відповідно до:

  • Zero to One
  • Art Of Atari ?
  • The Man Behind the Microchip

Богдан, дуже гарний вибір! Щось старе, щось нове, щось ігрове))) Було б дуже цікаво подивитися на список твоєї літератури 📚.

Дякую за ідею! Обов’язково поділюсь з DOU Books :)

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

Якщо інженер/менеджер не може розповісти про досягнення/результати, тобто відповіді на кшталт «ну, я розробляв features» / «ну, я керував командою та розмовляв з кастомером» / «ой, в мене NDA» (лол) — скоріше за все, ця людина дійсно не усвідомлювала, нащо вона там знаходилася, які проблеми вирішувала — а це дуже погано.
І погано всюди, де важливий саме результат, а не процес.

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

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

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

Програмування без цілей та результатів, які ти як інженер розумієш та освідомлюєш = «работа от забора до абєда» :)

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

Підтримую на всі 100!

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

У вас викривлене розуміння того, про що йшлося в статті. Але це ваше право)

Лаконічно і корисно, дякую!

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

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