Проєктний менеджмент і бізнес-аналіз 60-річної давнини: принципи роботи кібернетика Віктора Глушкова

Я Денис Гобов, понад двадцять років займаюся системним і бізнес-аналізом. Останні сім років моє професійне життя пов’язане з DataArt, де я працюю як Senior Business Analyst і лідер BA Capability. Також я є засновником і тренером школи бізнес-аналізу Art of BA та гостьовим лектором в НТУУ «КПІ ім. Сікорського».

Цьогоріч відзначають століття з дня народження Віктора Глушкова — фундатора української кібернетики, піонера світової комп’ютерної техніки та засновника Інституту кібернетики, де мені, до речі, пощастило навчатися на магістратурі та аспірантурі. DataArt IT Museum опублікував унікальні розшифровки аудіозаписів спогадів Глушкова, передані музею дочкою та онукою науковця. У цій статті я спробую обрати з мемуарів так звані правила Глушкова та перевірити їхню актуальність з точки зору сучасного IT-менеджменту.

Інститут кібернетики як тогочасний R&D-центр

Цікаво, що людина, яка працювала за часів СРСР, мала цілком прогресивний погляд на ІТ-галузь. Деякі з ідей Глушкова наразі можуть здаватися очевидними, але врахуйте — він дійшов до них самостійно і це в 50–60-х роках минулого століття.

1957 р. Віктор Глушков організував на базі лабораторії Обчислювальний центр Академії наук України, а ще за п’ять років потому — самостійний Інститут кібернетики. Якщо говорити сучасною мовою, інститут організували як R&D-центр, завданням якого було створення прикладних рішень в апаратній та програмній галузях. Його також можна сприймати як продуктову компанію, орієнтовану на державного замовника та промислові підприємства.

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

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

1. Пошук «якірного» замовника

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

Зі спогадів В. Глушкова: «Оскільки я мав схильність індустріалізувати виробництво, то одразу, крім роботи над зразком для „Києва“ (авт. — електронна обчислювальна машина „Київ“), для самого Обчислювального центру, я вирішив знайти багатого замовника, який здійснив би фінансування і постачання. Таким замовником виявилася Дубна, Об’єднаний інститут ядерних досліджень. До нас приїжджав адміністративний директор цього інституту, ми уклали договір і другий екземпляр машини робили для Дубни. Так ми одразу розв’язали питання фінансування і матеріально-технічного постачання, які розв’язати в умовах Академії наук було би просто неможливо».

Справді, пошук інвестора на ранній стадії розробки може вирішити багато фінансових труднощів проєкту. Як не згадати цитату з книги The Mom Test Роберта Фітцпатріка: «Не важливо, наскільки проблема є болісною для клієнта, якщо він не має на це платоспроможного попиту».

Але чи завжди клієнт розуміє свою проблему? Тут ми переходимо до наступного принципу Глушкова.

2. Замовник не завжди правий

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

«Із самого початку роботи в лабораторії з’ясувалося, що замовників на моделювання, наприклад, різноманітних дискретних систем дуже багато. Нас буквально засипали всякими проєктами постанов високих органів, що треба змоделювати те, змоделювати це тощо. Уже пізніше, після утворення Обчислювального центру, коли було створено відділ Мар’яновича Т. П., йому було доручено цим займатися. Я йому дав вісім тем, тобто вісім замовлень, карток замовників. А в нього шість осіб. Він прийшов до мене і каже: „Як же я це виконуватиму?“. Я відповів, що не треба робити ані того, ані другого, ані третього, ані восьмого, а роби СЛЕНГ (це її потім назвали СЛЕНГ) — універсальну мову для моделювання дискретних систем. Я зібрав усіх замовників, провів з ними виховну роботу, і вони погодились, що це саме те, що їм потрібно, і насправді вони неправильно склали картки»

Прочитавши про картки у спогадах, одразу зрозумів, що це елемент з тріади «Card, Conversation, Confirmation» для роботи з User Story. А інструмент-то практично сучасний! :)

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

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

3. Принцип єдності теорії та практики

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

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

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

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

4. Принцип єдності довгострокових і короткострокових цілей

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

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

Наприклад, класична проблема бізнес-аналізу та керування проєктами — відсутність дорожньої карти. А саме вона дозволяє, з одного боку, підтримувати прив’язку деталізованих задач до поставлених бізнес-цілей, а з іншого, утримувати активності з декомпозиції глобальної мети щодо задачі відповідно до SMART-критеріїв.
Про цей підхід наразі говорить кожен коуч, але 60–70 років тому цього не навчали, прочитати було ніде, ще й загальна практика йшла врозріз.

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

5. Керівник не має бути цілком зайнятим поточними справами

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

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

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

«Якщо навіть я бачу, що все робиться неправильно, то я направляю не конкретно, кажучи, що це питання треба було розв’язати таким чином, а за якимись інтегральними показниками»

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

6. Залучення практиків до викладання в закладах вищої освіти

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

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

І серед моїх знайомих є ті, хто проводили відкриті уроки в школах ще декілька років тому: розповідали про IT та те, до чого слід готуватися, на чому фокусуватися.

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

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

7. Дистанційна робота

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

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

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

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

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