Записки арт-директора самоучки: не рычите на програміста

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

Якщо це дійсно так — знімаю перед вами капелюха. Просто мрію познайомитися з вами і перейняти ваш досвід. Далі можете не читати — стаття не для вас.

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

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

У чому корінь всіх зол?
Несподівано для себе наштовхнувся на спосіб вирішення подібних проблем у книзі «Бізнес з нуля. Метод Lean Startup для швидкого тестування ідей та вибору бізнес-моделі» Еріка Рису, а саме в главі про методі «П'яти «Чому?». Суть методу в тому, що при виникненні будь-якої скрути потрібно п'ять разів послідовно задати питання «Чому?» і докопаешься до проблеми, що лежить в корені.

Почалося все з того, що, читаючи цю главу, я на автоматі задала не дає мені спокою питання: «чому замість того, щоб займатися новою фичей, ми знову переробляли стару і витратили на це два тижні?». Відповідь очевидна:
— Тому, що вона працювала неправильно і вводила користувача в оману.
Ставимо наступне питання:
— А чому вона працювала неправильно?
— Тому, що програмісти її так запрограмували.
— А чому вони так її запрограмували?
— Вони кажуть, що я їм так сказала. А їм ця ідея не подобалась з самого початку.
— А чому вони робили те, з чим не згодні і вважають нерозумним?
— Еее… вони не знають.

Чому програміст погоджується робити те, що не зрозумів або не схвалює? Тому, що: звик працювати за ТЗ; лінується думати; боїться здатися дурним; не хоче суперечити; вважає, що «начальник знає краще»; не хоче брати на себе відповідальність; встав на позицію героя а-ля «ось знову придумала єресь, а мені робити»… потрібне підкреслити.

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

image

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

Що робити?
Отже, з'ясували, що проблема елементарного нерозуміння, а зовсім не у відсутності професіоналізму окремо узятих працівників. Як боротися? Все документувати і писати ТЗ? Але, по-перше, воно застаріє ще раніше, ніж буде написано. А по-друге, мені хочеться, щоб програмісти брали участь у прийнятті рішень і несли за них відповідальність а не просто кодували. Даремно, чи що, ми зібрали кращих програмістів в СНД.

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

Теоретичні «можна було б, якби» звучать непереконливо і банально. Тому, ось вам результати живого непідробного експерименту.

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

Питаю, що не так. Він говорить «На сторінці Б в сайдбарі важлива кнопка, якщо його приховати, кнопка буде недоступна». Бінго! Елементарне нерозуміння ледь не призвело до кількох годинах марної роботи і негативу. Я кажу про одній сторінці — «А», а він зрозумів, що йдеться про всіх розділах. Одне просте питання, заданий вчасно заощадив купу часу і нервів.

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

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.