Back to basics. Яким має бути делівері в залежності від зрілості вашої організації

Мене звати Кирило Білобородько, я співпрацюю з ЕРАМ Україна у ролі Senior Delivery Manager. У продовження теми відновлення робочих процесів, яку ми нещодавно висвітлювали з Назарієм Поповим, хочу поділитись своїми роздумами і спостереженнями щодо побудови делівері з фокусом на методологію Адізеса.

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

Щоб бути на одній хвилі

Пропоную на початку трохи розібратись з термінами й теорією.

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

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

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

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

Делівері процес загалом передбачає три основні складові:

  • Процес безпосередньої розробки ПЗ

Щоб зрозуміти його детально, рекомендую прочитати літературу про гнучкий підхід до розробки, зокрема книги по SCRUM від Джефа Сазерленда та його послідовників, SEBOK (Software Engineering Body of Knowledge). Також буде корисно пройти сертифіковані курси Scrum Alliance, Agile lab: вони дають новачкам фундаментальне розуміння процесу делівері, методологій розробки, фреймворків тощо. Менеджерам-новачкам в ЕРАМ ми рекомендуємо внутрішню програму Еngineering Excellence — так в компанії називають сукупність підходів, які допомагають надійно розробляти продукти і сервіси. Еngineering Excellence передбачає заглиблення в роботу з репозиторіями, стратегії тестування та релізів тощо. Адже професійному менеджеру треба розуміти, як саме команда доставляє програмне забезпечення клієнту. Аналоги програми можна знайти на LinkedIn Learning, Udemy, Coursera та інших навчальних платформах.

  • Знання щодо архітектури ПЗ

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

  • Екаунт-менеджмент

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

Два слова про методологію Адізеса

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

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

Отже, ось як виглядає життєвий цикл організації на думку Іцхака Адізеса:

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

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

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

Отже, до наступних етапів.

«Дитинство»

На цьому етапі компанія формується. В аутсорсингових організаціях вже є клієнт (або клієнти), проєкти, інженери та/ або інші спеціалісти тощо. Якщо клієнт лише один і команда досить велика, то від успішності делівері насправді залежить виживання організації. Якщо ж портфель диверсифікований (а так буває, коли власники напрацьовують клієнтську базу поступово, починаючи з фрилансу), то делівері відіграє меншу роль. Відносини із замовниками будуються на особистих зв’язках, портфоліо досить диверсифіковане: це можуть бути проєкти за моделями Staff augmentation, Managed Services, Managed Capacity. Принцип формування компанії на цьому етапі визначає важливість делівері.

Що загрожує організації на етапі «Дитинства», якщо не вибудовувати процеси поставки продуктів та сервісів клієнту?

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

Ризик 2. Якщо компанія на етапі «Дитинства» все ж таки успішно працює з fixed price проєктами, то рано чи пізно власник перестає розвивати бізнес та керувати ним, а фокусується виключно на проєктному менеджменті. Це обертається негативними наслідками для інших напрямків: HR, маркетингу, адміністративного відділу тощо.

Я часто консультую СЕО і СТО компаній розміром у 30-40 осіб, які половину свого часу присвячують вирішенням ескалацій на проєктах. Вони вже мають РМ-ів, але жаліються на те, що ці співробітники недостатньо ініціативні, їм бракує відповідальності, тому всю роботу керівникам доводиться робити за них. На жаль, це ознака ключової помилки, якої власники компанії припустились 1-2 тому. Ось які сценарії для виходу з ситуації я рекомендую в такому разі:

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

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

Керівники можуть передати своїм підлеглим 100% відповідальності за нього (фінансову, технічну, керівну складову), пообіцяти допомогу у вигляді однієї сесії запитань-відповідей на тиждень і налаштування систем типу Delivery Health Monitor, які дозволяють менеджеру у будь-який час перевірити стан проєкту завдяки певним параметрам.

  • Залучити стороннього спеціаліста зі значним досвідом — Lead PM, Head of Delivery, Chief Delivery Officer тощо.

Керування проєктами та команду РМ-ів треба перевести у його зону відповідальності. Якість делівері та професійний рівень менеджерів можуть з часом змінитись на краще.

«Активний ріст»

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

Є три способи зробити це:

  1. За технологіями — групувати проєкти, які пишуться на Java, Python, C# тощо;
  2. За доменами — охорона здоров’я, електронна комерція, подорожі тощо;
  3. За формою контракту чи співпраці. Найчастіше є певна частина staff augmentation — коли проєктом повністю керує клієнт, а компанія лише надає спеціалістів з необхідною йому експертизою. Важливе завдання делівері організації в такому разі — проводити періодичні опитування серед членів команди (дізнатись, чи все влаштовує, як вони бачать свій подальший розвиток) та серед клієнтів (визначити, чи задоволені співробітниками, чи планують продовжувати співпрацю, запропонувати збільшення команди).

Кожен спосіб має свої плюси та мінуси. Загалом я вважаю, що на цьому етапі розвитку краще групувати проєкти за мовами програмування, типом робіт (розробка, тестування), форматом взаємодії. Це простіше, дозволяє досить прозоро розділити обов’язки та зони відповідальності і рости швидше. Розділення за бізнес-доменами на цій стадії може бути стратегічно вірним, але контрпродуктивним, адже значної доменної експертизи в компанії ще нема, а на кожний напрям потрібна людина з відповідним досвідом і сильними навичками керування проєктами. Я б рекомендував ділити проєкти за бізнес-доменами ближче до етапу «Юності».

Важливо на етапі «Активного росту»:

  • розібратись з типами контрактів. Вивчити формати співпраці з клієнтами та зрозуміти, у чому відмінності managed services, managed capacity, managed outcome;
  • ознайомитись з фреймворками для вірного масштабування команди: SCRUM, Agile, etc. Це може й не найнагальніше завдання, але на даному етапі в компанії вже з’являються крос-функціональні команди, яким треба вибудувати процеси обміну інформацією задля якісного делівері.

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

Наприклад, ви можете ввести розподіл на Staff augmentation та End-to-end delivery. Керувати цими напрямками повинні різні люди. Першій групі потрібен професіонал, який більше сфокусований на роботі з людьми, відносинах з клієнтами, підвищенні продажів. На цю посаду підійдуть спеціалісти, які знаються на екаунт-менеджменті, фінансах, побудові довгострокових контактів із замовниками і загалом розуміють їхній бізнес. Такий менеджер може впоратись з портфоліо в 20-30 осіб, які розкидані по різних Staff augmentation проєктах, та не обов’язково матиме сильний технічний досвід. Цього спеціаліста можна виростити з одного з співробітників. А от для End-to-end delivery людині краще мати сильну технічну експертизу, щоб розуміти та оцінювати результати роботи техлідів, передбачаючи виникнення можливих проблем через невірні рішення. Я б рекомендував залучати на цю роль сильного спеціаліста з ринку або сприяти розвитку в цей бік одного з техлідів.

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

«Юність»

Цей етап розпочинається, коли компанія виростає до 80-200 співробітників, іноді — 300-400. Найчастіше відбувається позиціонування та фокусування саме на бізнес-доменах, формується вертикальна пропозиція, коли компанія пропонує клієнтам стати успішними в їхньому напрямку. Замовники — це частіше за все представники середнього та великого бізнесу, значно рідше — малого.

На даному етапі гостро постає питання створення задекларованих делівері процесів. Хоча це актуально і на попередніх щаблях, але під час «Дитинства» це більше схоже на інструкцію і формальну фіксацію очікувань, а під час «Активного росту» — на більш-менш формалізовані процедури і найкращі практики. На етапі «Юність» мусимо мати вже якісніший набір інструментів. Зокрема делівері метрики, адже проєкти вже починають вимірювати якість, прогнозованість, обсяг вироблення, темп розробки, стабільність спринта, зміни в ньому, стабільнітсь релізів тощо. Менеджери відстежують компоненти, які в класичному проєктному управлінні демонструють scope creep (або зсув обсягу роботи, випередження або відставання від розкладу). Під час «Юності» підхід до роботи має ставати більш формалізованим.

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

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

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

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

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

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

«Розквіт»

На етапі розквіту компанія може налічувати 500-1000 співробітників. Але для точнішої класифікації варто зазначити, що багато залежить від клієнтів. Якщо у компанії за всю історію існування було лише 2-3 великих замовники, то є ризик, що вона буде недостатньо зрілою, адже не мала нагоди розвивати делівері завдяки старту нових проєктів. Вони виросли кількісно, але все ще знаходяться на більш базовому рівні зрілості.

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

Життєвий приклад: я беру участь у щотижневих зустрічах керівників великих (на 100 і більше спеціалістів) екаунтів і бачу, що виклики на шляху зростання дуже часто схожі:

  • Як сегментувати 30-40 проєктів в межах одного екаунту на програми так, щоб система була під контролем і тиск не ставав надлишковим?
  • Як вибудувати інженерну та менеджерську спільноту для обміну досвідом в рамках такого екаунту?
  • Як налагодити обмін досвідом та запобігти повторенню одних і тих самих помилок?
  • Як зробити так, щоб ключові люди знали про ініціативи колег та могли використовувати досвід один одного задля кращого делівері?
  • Як сформувати дискавері-групу, яка стартуватиме програми для людей всередині екаунту?

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

Тож як налагодити вертикальну взаємодію команд? Моя рекомендація — створити горизонтальні зв’язки: окремі «клуби за інтересами», які пронизують організацію на різних рівнях. В ЕРАМ таку роль виконують зокрема Центри компетенції з різних дисциплін: делівері менеджменту, Java, Python, Testing та багатьох інших. За моделлю Spotify такі спільноти називаються трайбами і вони працюють незалежно від приналежності до певного проєкту чи клієнту. Коли найяскравіші представники екаунтів чи проєктів починають ділитися знаннями, це стимулює їхній розвиток і допомагає знайти більше приводів для партнерства. Обмін знаннями в сферах технологій, бізнесу, доменів допомагає скоріше зростати і виходити на новий рівень всій організації.

«Стабільність»

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

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

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

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

На етапі «Стабільності» важливо створювати систему, механізми, що дозволяють окремим вертикалям співпрацювати — тобто, продовжувати розпочате за часів «Розквіту». Але з декотрим доповненням: необхідно, щоб команди співпрацювали і компанія не рухалась у бік «аристократизації» та бюрократії, але водночас важливо створювати необхідну кількість навчальних матеріалів і процесів для того, щоб вона не поверталася на попередні етапи.

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

«Спад», «Аристократизм»

Частина компаній, які пішли далі, ніж етап «Стабільності», демонструють риси «Аристократизму». Скоріш за все ці гравці присутні на ринку понад 15 років.

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

Формалізація процесів, опора на людей, які роками працюють на компанію і «чекають пенсії», спротив новому — все це вбиває підприємницький дух і те, що Адізес називав Вітаміном Е.

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

Насамкінець

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

  1. Підтримуйте підприємницький дух та новачків, які прагнуть щось змінити на краще.
  2. Зберігайте та розвивайте делівері культуру. Постійно рефлексуйте щодо того, як робляться поставки продукту у вашій компанії, що означає «якісне делівері», хто такий — делівері менеджер. Ставте ці запитання собі, а потім — за допомогою онбордингу, навчання, тренінгів тощо — намагайтесь пояснити їх новачкам, які долучаються до вашої організації. Вони мають розуміти, як побудовані процеси у вашій організації, яких принципів ви дотримуєтесь.
  3. Створюйте атмосферу співпраці між людьми, проєктами, екаунтами. Обмінюйтесь досвідом і накопичуйте знання. Це важливо на кожному етапі розвитку організації, адже так ви зможете бути ефективнішими і не дублюватимете роботу один одного. Люди своєю чергою робитимуть менше помилок і зможуть краще застосовувати свій інтелектуальний потенціал.

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

Корисна література за темою

  1. Іцхак Адізес: «Управління життєвим циклом корпорацій»
  2. Іцхак Адізес: «Ідеальний керівник. Чому їм неможливо стати»
  3. Стівен Кові: «7 навичок надзвичайно ефективних людей»
  4. Юрген Аппело: «Менеджмент 3.0. Agile-менеджмент. Лідерство та управління командами»
  5. Майк Кон: «Оцінювання і планування в Agile»
  6. Роб Коул, Едвард Скотчер: «Блискучий Agile. Практичний посібник для проєкт-менеджерів із використання Agile, Scrum, Kanban»

Ілюстрації для статті зробила Аліна Петрова, Experience Designer, EPAM.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному7
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

Дякую за статтю. Особливо приємно, коли автор наприкінці приводить перелік рекомендованої літератури. За це окрема подяка!

Я пропоную залучати РМ-ів у presale-роботу та надавати їм доступ до всієї інформації, яка стосується проєкту.

Керівники можуть передати своїм підлеглим 100% відповідальності за нього (фінансову, технічну, керівну складову

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

Це реальні випадки з життя нашого ІТ які відбулись в компаніях поки я там працював.
І це були норм компанії на 200+ людей з зп вище 3 квартилю.

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

Стаття класна, аж засумував за нормальними менеджерами а не тим що в мене зараз...

Стаття виключно для менеджерів, управлінців. Інформації для технічних спеціалістів 2%. По назві чекала іншого змісту, автору cheers ! за старання, але знову ж таки це для досить великих команд.

Дякую за коментар. Стаття дійсно вузькоспеціалізована. Насамперед вона для Project, Delivery та Program Manager-ів. Також ця інформація буде корисна для C-Level керівників невеликих та середніх за розміром компаній.

Спасибо за интересную статью и литературу

SEBOK — Software Engineering BODY of Knowledge :)

Дякую, дійсно. Виправимо.

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

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