«Ми звільнили топ-спеціаліста. Це було найкраще наше рішення». Колонка freeCodeCamp

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

У своєму матеріалі, що опублікували freeCodeCamp.org, Джонатан розповідає про помилки геніального розробника, які призвели його до звільнення. Статтю українською мовою підготувало Бюро перекладів для бізнесу MK:translations. Ми публікуємо адаптований та скорочений переклад.

Доктор Джекіл

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

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

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

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

Назвемо таку людину Рік. 

Зауважимо, що ця історія НЕ про freeCodeCamp.org. Вона не розповідає про когось із нашої організації. Історією поділився з виданням розробник. Деталі оповіді змінено. 

Хто такий Рік? 

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

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

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

Незабаром Рік перестав відвідувати наради. Просто не мав на них часу: так багато йому доводилося кодити. Рік зачинився в кабінеті. Його дошка валялася без діла. У нього більше не було часу навчати когось, тому що мав забагато власних завдань. 

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

На дашборді нашого проєкту зелені позначки змінилися на жовті. Жовті — на червоні. Червоні вогники почали миготіти. Один за одним статуси завдань змінювалися на «Перешкода». Усі чекали на Ріка.  

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

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

Щодня розробник ставав дедалі більш агресивним та ізольованим. Маска спадала. Джекіл ставав Гайдом. 

Як вдалося врятувати проєкт? 

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

Мене направили дізнатися, чи можна цю справу врятувати. Моєю першою нарадою в межах проєкту була вище згадана зустріч з «Альбертом Ейнштейном». Я занурився у вихідний код. Рік мав рацію: ніхто не міг зрозуміти те, що він створив. Крім нього самого. Це було втіленням його розуму. Щось дуже дотепним, щось — копіпастом. Усе доволі своєрідне й зовсім не задокументоване. 

Я пішов до нашого ІТ-директора з вердиктом. Тільки Рік міг би обслуговувати цей продукт. До того ж кожен день роботи відсував дату здачі проєкту на тиждень назад. Рік руйнував наш продукт швидше, ніж створював його. 

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

Як Рік відреагував на це? Так, як тільки міг. Він вибухнув гнівом. 

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

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

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

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

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

Продукт Ріка підтримував активний робочий процес із понад п’ятнадцятьма тисячами перестановок. Насправді 99% наших випадків використання йшли одним із трьох шляхів. Команда чітко їх запрограмувала. Це видалило понад 30% роботи Ріка. У продукті не було спеціальних компонентів, що кодувалися вручну для кожного завдання. Команда прибрала всі залежності, які можна купити, а не створювати. 

Це видалило сотні годин роботи Ріка. Водночас усунуло тисячі годин технічної заборгованості. Ми отримали згоду від спонсора проєкту на вимкнення деякої функціональності для крайніх випадків. Ця функція обслуговувала лише 5% нашої дозапускової групи користувачів і відповідала приблизно за чверть складності продукту. 

Далі повторно випустили продукт для цієї групи. Він складався на 10% з оригінального коду Ріка, який був досить стабільним. Ще містив кілька тисяч рядків нового коду, щоб виправити приблизно 150 000 рядків незрозумілого Рікового безладу. 

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

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

Команда перейшла до інших продуктів Ріка й викинула звідти старий код. Вони перевипустили ще один його проєкт за три місяці злагодженої роботи. У Ріка на розроблення продукту пішло три роки. 

У команді не залишилося жодних Ріків. Не було божевільних геніїв, які будували все з нуля. Проте наша продуктивність стала як ніколи високою. 

Рік дуже талановитий розробник. Він міг розв’язувати важкі задачі бізнес-логіки та створювати складні архітектури для підтримки своїх високих задумів. Однак не міг навчитися ефективно працювати в команді. 

Майстри-самітники — це круто. Однак хмарочоси будуються командами.

У чому була проблема Ріка?

Рікова робота була деструктивною в кількох аспектах. По-перше, він створив культ залежності від себе. Будь-яка проблема із часом ставала проблемою Ріка. Це був міф, який він підтримував. Розробники навчилися припиняти зусилля і просто чекати на Ріка. 

По-друге, він писав код, який неможливо було б підтримувати. Він ніколи нічого не документував і не тестував. Тому зазнав невдачі, навіть попри свій інтелект. Його віра у власну непогрішність узяла гору над здоровим глуздом. 

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

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

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

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

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

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