[Из песочницы] Записки арт-директора самоучки: не рычите на программиста
Вы с небольшой командой создаете стартап (неважно, мобильное, веб или настольное приложение). Возможно, часть команды работает удаленно и вы с ними общаетесь по скайпу. И все у вас прекрасно. Разработка идет небольшими итерациями, проектировщик проектирует, дизайнер рисует, программисты получают четкую задачу и воплощают ее в элегантный и гибкий программный код, который не приходится переделывать. Руководство довольно, в команде царит взаимопонимание и доверие, проект движется к завершению и все уже видят себя пожинающими сладкие лавры победы.Если это действительно так — снимаю перед вами шляпу. Просто мечтаю познакомиться с вами и перенять ваш опыт. Дальше можете не читать — статья не для вас.У нас все немного по-другому, хотя исходные данные те же. Стартап, веб-приложение, распределенная команда, небольшие итерации. Есть общее видение и цель, которую хотим достичь. Нет ТЗ и четкого описания требований (стартап же). Руководитель руководит, проектировщик проектирует, сам же рисует и ставит задачи программистам, программисты программируют. Но почему-то, мало что делается с первого раза. Решение простых задач растягивается на недели. Вновь и вновь возвращаемся к обсуждению одних и тех же вопросов. Всплывают неоправданные ограничения из разряда «если здесь сделать так, где-то там сломается нужная штука». В приложении обнаруживаются странные артефакты, предназначение которых никто не может объяснить.
Часто в такой ситуации начинаются взаимные претензии и поиск виноватых. А это только разобщает команду, замедляет разработку, снижает мотивацию и командный дух.
В чем корень всех зол? Неожиданно для себя натолкнулась на способ решения подобных проблем в книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» Эрика Риса, а именно в главе о методе «Пяти «Почему?». Суть метода в том, что при возникновении любого затруднения нужно пять раз последовательно задать вопрос «Почему?» и докопаешься до проблемы, лежащей в корне.Началось все с того, что, читая эту главу, я на автомате задала не дающий мне покоя вопрос: «почему вместо того, чтобы заниматься новой фичей, мы опять переделывали старую и потратили на это две недели?». Ответ очевиден: — Потому, что она работала неправильно и вводила пользователя в заблуждение.Задаем следующий вопрос: — А почему она работала неправильно? — Потому, что программисты ее так запрограммировали.– А почему они так ее запрограммировали? — Они говорят, что я им так сказала. А им эта идея не нравилась с самого начала.– А почему они делали то, с чем не согласны и считают неразумным? — Эээ… они не знают.
Почему программист соглашается делать то, что не понял или не одобряет? Потому, что: привык работать по ТЗ; ленится думать; боится показаться глупым; не хочет перечить; считает, что «начальник знает лучше»; не хочет брать на себя ответственность; встал в позицию героя а-ля «вот опять придумала ересь, а мне делать»… нужное подчеркнуть.
В итоге наблюдаем следующую картину. Проектировщик сказал одно, программист услышал другое. В душе ругнулся, поморщился, но виду не подал и пошел запиливать. Пилил неделю недоумевая, зачем такое могло понадобиться. Запилил. Принес. На вопрос «Что это?» отвечает — «ты мне сама сказала так сделать — я сделал». Но я-то имела в виду совсем другое! В результате потеряна неделя, вместо приложения — монстр на костылях, командный дух ниже плинтуса и все друг друга обвиняют.
И это только одна маленькая задачка. А сколько таких задачек в относительно большом проекте? Десятки, сотни? И за одну цепляется другая, потом третья и очень быстро наступает момент, когда исправить кривое решение чрезвычайно трудно потому, что на нем базируется целая падающая башня из кода написанного позже. Проект распухает, недовольство растет, сроки срываются.
Что делать? Итак, выяснили, что проблема в элементарном недопонимании, а вовсе не в отсутствии профессионализма отдельно взятых сотрудников. Как бороться? Все документировать и писать ТЗ? Но, во-первых, оно устареет еще раньше, чем будет написано. А во-вторых, мне хочется, чтобы программисты участвовали в принятии решений и несли за них ответственность, а не просто кодировали. Зря, что ли, мы собрали лучших программистов в СНГ.Есть и другой вариант — высказывать свои сомнения, слушать, что говорят другие члены команды, задавать вопросы и пытаться разобраться в том, почему предлагается то или иное решение. Ведь если вдуматься, проблемы можно было бы избежать, если бы программист вместо «Надо — сделаю» сказал «Бред какой, не буду я это делать потому, что…». Или проектировщик потрудился удостовериться, что его правильно понимают, а услышав угрюмый тон не отмахнулся, а спросил «Что тебе не нравится? Давай обсуждать».
Теоретические «можно было бы, если бы» звучат неубедительно и банально. Поэтому, вот вам результаты живого неподдельного эксперимента.
Делаем довольно сложное веб-приложение с несколькими разделами, кучей контента и различающейся версткой на страницах. Есть нерешенный пока вопрос с сайдбаром, в некоторых разделах. Он загромождает страницу на узком разрешении, но содержит полезные элементы навигации. И мешается, и убрать нельзя. Говорю верстальщику «на странице А сайдбар не критичен, давай его прятать на маленьких экранах — будет больше места для полезного контента». Верстальщик односложно отвечает «надо — сделаю». Думаю «Ага, попался! Явно ему что-то не нравится».
Спрашиваю, что не так. Он говорит «На странице Б в сайдбаре важная кнопка, если его скрыть, кнопка будет недоступна». Бинго! Элементарное недопонимание чуть не привело к нескольким часам бесполезной работы и негативу. Я говорю об одной странице — «странице А», а он понял, что речь идет обо всех разделах. Один простой вопрос, заданный вовремя сэкономил массу времени и нервов.
Может показаться, что такой подход приводит к лишней болтовне и снижает эффективность работы. Мол, зачем тратить время на разговоры, разберемся по ходу. Но на практике, он сокращает время разработки, снижает количество переделок и повышает качество продукта. Более того, такой подход позволяет сближать команду и поднимать командный дух благодаря тому, что люди общаются, совместно находят решения, вырабатывают общее понимание и единую точку зрения.
Постепенно начинаю тестировать такой подход на наших программистах. Получается не всегда. Но когда получается, вижу искреннюю радость от того, что люди наконец-то начинают понимать, что они делают. Вижу энтузиазм, заинтересованность и ускорение работы, вижу желание понять и разобраться. Да, ради этого иногда приходится откладывать свои собственные горящие дела и тратить время на объяснения или, наоборот, вопросы и углубление в те сферы, которые меня напрямую не касаются. Но готова поспорить, что оно того стоит.
Какова же мораль сей басни? А мораль очень простая. Если в команде возникают споры о том, кто виноват в срыве сроков, появляются взаимные претензии и обвинения, то худшее что можно сделать — это устроить охоту на программистов ведьм. Гораздо разумнее сесть, взять одну маленькую конкретную проблемную ситуацию и начать рыть вглубь — докопаться до проблемы лежащей в корне. Она есть всегда. Ее только нужно найти. Это может быть что угодно — от непродуманных процессов и медленного интернета до привычек и культурных различий. Часто проблему можно легко устранить, иногда нужно обойти или научиться с ней жить, но первый и самый важный шаг — ее обнаружить и признать. Одно это способно поднять командный дух, сблизить команду и повысить эффективность работы. А это — именно то, что нужно любому стартапу.
