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

Вы с небольшой командой создаете стартап (неважно, мобильное, веб или настольное приложение). Возможно, часть команды работает удаленно и вы с ними общаетесь по скайпу. И все у вас прекрасно. Разработка идет небольшими итерациями, проектировщик проектирует, дизайнер рисует, программисты получают четкую задачу и воплощают ее в элегантный и гибкий программный код, который не приходится переделывать. Руководство довольно, в команде царит взаимопонимание и доверие, проект движется к завершению и все уже видят себя пожинающими сладкие лавры победы.

Если это действительно так — снимаю перед вами шляпу. Просто мечтаю познакомиться с вами и перенять ваш опыт. Дальше можете не читать — статья не для вас.

У нас все немного по-другому, хотя исходные данные те же. Стартап, веб-приложение, распределенная команда, небольшие итерации. Есть общее видение и цель, которую хотим достичь. Нет ТЗ и четкого описания требований (стартап же). Руководитель руководит, проектировщик проектирует, сам же рисует и ставит задачи программистам, программисты программируют. Но почему-то, мало что делается с первого раза. Решение простых задач растягивается на недели. Вновь и вновь возвращаемся к обсуждению одних и тех же вопросов. Всплывают неоправданные ограничения из разряда «если здесь сделать так, где-то там сломается нужная штука». В приложении обнаруживаются странные артефакты, предназначение которых никто не может объяснить.

Часто в такой ситуации начинаются взаимные претензии и поиск виноватых. А это только разобщает команду, замедляет разработку, снижает мотивацию и командный дух.

В чем корень всех зол?


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

Началось все с того, что, читая эту главу, я на автомате задала не дающий мне покоя вопрос: «почему вместо того, чтобы заниматься новой фичей, мы опять переделывали старую и потратили на это две недели?». Ответ очевиден:
– Потому, что она работала неправильно и вводила пользователя в заблуждение.
Задаем следующий вопрос:
– А почему она работала неправильно?
– Потому, что программисты ее так запрограммировали.
– А почему они так ее запрограммировали?
– Они говорят, что я им так сказала. А им эта идея не нравилась с самого начала.
– А почему они делали то, с чем не согласны и считают неразумным?
– Эээ… они не знают.

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

В итоге наблюдаем следующую картину. Проектировщик сказал одно, программист услышал другое. В душе ругнулся, поморщился, но виду не подал и пошел запиливать. Пилил неделю недоумевая, зачем такое могло понадобиться. Запилил. Принес. На вопрос «Что это?» отвечает – «ты мне сама сказала так сделать – я сделал». Но я-то имела в виду совсем другое! В результате потеряна неделя, вместо приложения – монстр на костылях, командный дух ниже плинтуса и все друг друга обвиняют.

image

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

Что делать?


Итак, выяснили, что проблема в элементарном недопонимании, а вовсе не в отсутствии профессионализма отдельно взятых сотрудников. Как бороться? Все документировать и писать ТЗ? Но, во-первых, оно устареет еще раньше, чем будет написано. А во-вторых, мне хочется, чтобы программисты участвовали в принятии решений и несли за них ответственность а не просто кодировали. Зря, что ли, мы собрали лучших программистов в СНГ.

Есть и другой вариант – высказывать свои сомнения, слушать, что говорят другие члены команды, задавать вопросы и пытаться разобраться в том, почему предлагается то или иное решение. Ведь если вдуматься, проблемы можно было бы избежать, если бы программист вместо «Надо – сделаю» сказал «Бред какой, не буду я это делать потому, что...». Или проектировщик потрудился удостовериться, что его правильно понимают, а услышав угрюмый тон не отмахнулся, а спросил «Что тебе не нравится? Давай обсуждать».

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

Делаем довольно сложное веб-приложение с несколькими разделами, кучей контента и различающейся версткой на страницах. Есть нерешенный пока вопрос с сайдбаром, в некоторых разделах. Он загромождает страницу на узком разрешении, но содержит полезные элементы навигации. И мешается, и убрать нельзя. Говорю программисту «на странице А сайдбар не критичен, давай его прятать на маленьких экранах – будет больше места для полезного контента». Программист односложно отвечает «надо – сделаю». Думаю «Ага, попался! Явно ему что-то не нравится».

Спрашиваю, что не так. Он говорит «На странице Б в сайдбаре важная кнопка, если его скрыть, кнопка будет недоступна». Бинго! Элементарное недопонимание чуть не привело к нескольким часам бесполезной работы и негативу. Я говорю об одной странице – «странице А», а он понял, что речь идет обо всех разделах. Один простой вопрос, заданный вовремя сэкономил массу времени и нервов.

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

Постепенно начинаю тестировать такой подход на наших программистах. Получается не всегда. Но когда получается, вижу искреннюю радость от того, что люди наконец-то начинают понимать, что они делают. Вижу энтузиазм, заинтересованность и ускорение работы, вижу желание понять и разобраться. Да, ради этого иногда приходится откладывать свои собственные горящие дела и тратить время на объяснения или, наоборот, вопросы и углубление в те сферы, которые меня напрямую не касаются. Но готова поспорить, что оно того стоит.

Какова же мораль сей басни?


А мораль очень простая. Если в команде возникают споры о том, кто виноват в срыве сроков, появляются взаимные претензии и обвинения, то худшее что можно сделать – это устроить охоту на программистов ведьм. Гораздо разумнее сесть, взять одну маленькую конкретную проблемную ситуацию и начать рыть вглубь – докопаться до проблемы лежащей в корне. Она есть всегда. Ее только нужно найти. Это может быть что угодно – от непродуманных процессов и медленного интернета до привычек и культурных различий. Часто проблему можно легко устранить, иногда нужно обойти или научиться с ней жить, но первый и самый важный шаг – ее обнаружить и признать. Одно это способно поднять командный дух, сблизить команду и повысить эффективность работы. А это – именно то, что нужно любому стартапу.

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 31
  • +6
    Попробуйте применять шире, не только в команде стартапа. Это частая проблема любых взаимоотношений. И почувствуете как они улучшаются и с семьей и с друзьями. И настанет мир во всем мире…
    • 0
      :) Спасибо! Начнем с малого. А потом доберемся и до мира во всем мире
      • +2
        Я считаю что это тоже не корень проблемы, у Вас на этом все не закончится и мир во всем мире не настанет.

        Мое ИМХО
        У Вас либо нет тимлида, либо у Вас очень плохой тимлид, раздолбай. Хороший тимлид всегда сможет правильно понять дизайнера, проектировщика и уже в простом виде отдать своей команде задачи, так сказать на своем языке, потому что программист может отлично писать код, но он ничерта Ваш язык не понимает, более того он будет изо всех сил стараться понять, но через какое то время забьет, просто кому то это дано, кому то нет, а кто то вообще не хочет таким заниматься.

        Это все тоже самое если бы я сейчас начал управлять дизайнерами, и получилась бы такая же ситуация, мне бы нарисовали отличный, красивый дизайн, но он бы не работал или не продавал. Так что если бы мне потребовался хороший и большой объем дизайна, я бы потребовал арт директора и 2-х дизайнеров, дальше я бы полностью объщался с арт директором, т.к. мы максимально точно сможем друг друга понять.

        Так же все это блюдо надо в обязательном порядке подавать в виде скрума(scrum).
        Он поможет сплотить 2 команды

        В общем тимлид это контроллер для команды программистов и человеко понятный интерфейс для внешнего мира

        Так же я Вам настоятельно рекомендую прочитать книгу deadline Тома Демарко
        • +2
          в виде чего, извините? скрум, бус, рун, Крум?

          По теме, если у вас наемные работники, то ставьте им полную задачу. Если партнеры в стартапе, то относитесь как к партнерам, а не исполнителям. Начинается-то все так: «Эй, ***, хватит пахать на дядю, забабахаем свой проект и станем миллионерами! Только ты все сделай, переделай, отладь и почини, а потом дам тебе премию зарплату, а может и полторы!» А потом зачастую «Вы занимались не работой, а переделыванием, потому что не угадали мои мысли!»
        • 0
          Сори. Я просто хотел Вам ответить и увлекся, надо было отдельным комментом писать
        • +28
          >>> Почему программист соглашается делать то, что не понял или не одобряет? Потому, что: привык работать по ТЗ; ленится думать; боится показаться глупым; не хочет перечить; считает, что «начальник знает лучше»; не хочет брать на себя ответственность; встал в позицию героя а-ля «вот опять придумала ересь, а мне делать»… нужное подчеркнуть.

          Всё это неправда, просто к доводам программиста обычно никто не считает нужным прислушиваться.
          • +12
            Печальный факт. И не только «программиста». Очень часто со стороны разработчиков высказываются мнения по поводу того, как и что может случиться. Как показывает практика, в большинстве случаев негативные прогнозы сбываются, если ко мнению так и не прислушались.
            • 0
              Именно так и есть. Если не прислушались к мнению программиста, менеджера и многих других — получается ерунда. Что-то вроде лебедя, рака щуки — каждый тянет в свою сторону, и дело либо не движется, либо движется совсем не туда. И, как и написал автор, решить проблему можно потом только добравшись до всех косяков, допущенных в процессе. Да и не только для стартапов это справедливо.
            • +7
              Обычно выглядит так:
              — А ну-ка, сделай мне фичу ХХХ!
              — Ок, сделаю, но потом не удастся нормально реализовать УУУ
              — А, пофиг, придумаем че-нить!

              — КАКОГО #%$$%^ НЕ РАБОТАЕТ УУУ????777?777
              • 0
                У нас это называлось экстремальным программированием и код «должен быть в постоянном состоянии рефакторинга».
                Agile он такой…
              • +3
                Соглашается по нескольким причинам — устал спорить и доказывать свою точку зрения, к примеру. Или его понимание поставленной задачи разница с понимаем тем, кто ее поставил.

                ИМХО самая большая проблема разработки приложений (и не только в стартапах) — отсутствие грамотного продумывания архитектуры системы, что Вы и подтвердили — нет четкого ТЗ. Работаем работу, программируем, а там посмотрим. В результате и получается абы что. А если это не стартап, а активно работающая компания, где все надо сделать вчера, то результат еще плачевнее, ибо начальство прессует непостартаповски :)
                • 0
                  Скажите, а как вы думаете, почему к мнению программиста часто не прислушиваются? Вроде как, все от этого в итоге страдают. Хочу собрать мнения, причем и той, и другой стороны.
                  • 0
                    Чтобы к мнению программиста (или любого другого человека) прислушались, это мнение нужно уметь правильно подать. А это требует иных компетенций, чем есть у большинства программистов. Поэтому Вам и написали выше про тимлида — это тот человек, который сочетает в себе необходимые качества.
                    • +2
                      А потом вы еще 4 раза спросите «почему»?

                      Смотрите, у вас вроде как в статье посыл — «не вините программистов», а в итоге все выкладки приводят к тому что они и «виноваты», в частности потому что не думают за других. Программист он на то и программист, чтобы программировать, воплощать идею в код. Чтобы оценивать идею, надо тогда программистов называть не программистами, а как-то иначе. Например, для начала, можно даже разработчиками (системы). Тогда и мнение будет ценнее. Возможно. Кстати есть практика, которая если и не поощряет возврат задач, то как минимум предусматривает — канбан называется.

                      Более того. Такие же претензии можно предъявить и к тестированию, и к менеджеру, и даже к клиенту («а чего он в поддержку предложение не написал, молча ушел и все?»). Хотя начинать стоит с дизайнера системы конечно (или кто там его роль выполняет — гейм-дизайнер, проектировщик).

                      Вот смотрите. ТЗ бывают разные. Бывают и полезные. Называются прототипами. Не теми прототипами, которые потом становятся основой продукта, а теми, которые не переиспользуются в качестве основы для будущего продукта. Это могут быть и макеты. У вас есть же список фич? Это уже почти ТЗ. Вобщем мой ответ на все ваши почему — никто не следит за непротиворечивостью требований и их приоритетами.
                      • 0
                        Я вам отвечу так: потому что, как правило, никто не хочет вникать в техническую сторону вопроса. Ниже есть очень хороший комментарий про «приклей звезду». Обычно именно так всё и происходит. Но при этом арт-директор и прочие дизайнеры уверены в чём угодно — в том, что программист ленив, боится показаться глупым, не хочет перечить и т.п., кроме реальной причины. А реальная причина заключается в том, что изначально никто не продумал архитектуру как следует (чаще всего потому, что в постановке ТЗ собственно программист и не участвовал). Прототипы приложения (на которых можно отработать юзабилити, почувствовать как оно будет выглядеть, наконец узнать то ли это, что хотел клиент) тоже никто не считает нужным делать, уж не знаю почему, дорого наверно, или времени нет.

                        Вы пишете: "… Всплывают неоправданные ограничения из разряда «если здесь сделать так, где-то там сломается нужная штука». Вот объясните, почему вы решили, что эти ограничения неоправданные?

                        В общем вы изначально делаете неверный вывод, по сути сваливая всю вину на программиста. Я более чем уверен, что у вас в рабочем процессе есть множество иных проблем и они гораздо важнее, чем коммуникации между отделами.
                        • 0
                          Потому что «Этим программистам лишь-бы не делать нифига. Это всё отмазки».
                          Потому что «Идея гениальна, я точно знаю, просто не все способны это понять».
                          Потому что «Мне лучше знать как правильно».
                          И так далее, в том-же духе.

                          Самое печальное, что после *цатой тупой задачи, программист перестаёт спорить и что-то доказывать-объяснять, т.к. бесполезно, и начинает тупо делать что скажут. Отношение его, к тому что он делает, при этом соответствующее.
                          Потом он и вовсе уходит (увольняется), т.к. ему надоело заниматься реализацией тупых идей, переделывая одно и то-же по нескольку раз, видя как его код в очередной раз летит в /dev/null.
                      • +4
                        Проблема ещё и в том что обычно (не всегда, но обычно), решающее слово за человеком который мало понимает в том как по факту работает разрабатываемая система. Не на уровне «мы нажмём тут и вон там выпадет меню», а на уровне «эвентов», структуры данных, используемых технологий и т.д.

                        В итоге когда программисту говорят — а вот тут приклей звезду! — все вокруг думают что отличие того что есть от того что будет «звезда». Программист же видит как в стройный каркас здания которое он так усердно планировал и собирал вклинивается какая та «звезда» которая полностью противоречит имеющейся логике и структуре. И он бы рад перестроить всё с учётом этой непонятной «звезды» так что бы и она имела право на жизнь. Более того, он уже придумал как сделать так что бы в будущем можно было втыкать эти звёзды куда попало! Но звезда как всегда нужна вчера! И бедняга программист должен собственноручно увечить своё детище.

                        В итоге, большинство проектов (их кодовая база) выглядят как нагромождение костылей.
                        • –1
                          Разработчик и дизайнер веб приложений не может быть не программистом, потому что веб страницы состоят из кода. Ему надо понимать, какие он задачи ставит. Так что тот, кто принимает решения, определенно тоже программист.
                        • +1
                          У нас вообще случай был. Пришёл заказ на установку. Заказчик выслал ТЗ.
                          В ТЗ был смутно описан алгоритм работы шкафа автоматики. Стали звонить и выяснять подробности.
                          Но оказывается, заказчик сам ещё не знает, что он хочет от шкафа. Сейчас ему нужно только железо, а по программе «пусть при пуске загорается лампочка „Работа“, пока достаточно, потом приедете и будем разбираться в алгоритме»))
                          • 0
                            Мне кажется или все можно свести к двум простым тезисам:
                            1) Максимально вытягивать информацию из клиента до начала работы и дотошно расписывать каждый шаг, скрепляя все договором.
                            2) Оплачивать работникам труд и время сверх плана и всегда думать, чтобы не делать бессмысленной работы.
                            • –1
                              1) Не всегда есть клиент, из которого можно вытянуть всю информацию. А если даже есть, то он может не представлять себе четко задачу. Ни разу не видела клиента, который бы предоставил исчерпывающее описание будущего проекта :) А если вы создаете стартап, то сами не представляете, как и что делать. Приходится пробираться на ощупь, не растеряв по дороге ценнейших программистов.

                              2) Полностью поддерживаю!
                              • 0
                                если из клиента все вытягивать приходится по крупицам, то с ним однозначно не стоит работать, как правило это часто заканчивается плохо, надо уметь отказываться от клиента.

                                Если клиент сам не знает что хочет, то ему надо будет в этом обязательно помочь

                                Если Вы кругами ходите с клиентом и не можете с ним придти к какой то цели и общему пониманию, то Вам надо поучиться переговорам
                            • 0
                              Так если он не представляет что хочет, вы как работать начинаете, наугад?
                              • +1
                                Откройте для себя Scrum
                                • 0
                                  Присоединюсь к мнению. Причем не обязательно Scrum. Откройте для себя какую-то методологию. В большинстве из них есть решения для типовых проблем. Например, в упомянутом Scrum это этап оценки. Проведите обсуждения требований, оцените их трудоемкость, прикиньте как это будет тестироваться. Разрешиться очень большое количество вопросов как со стороны разработчиков/дизайнеров, так и со стороны аналитиков/руководителей. После итерации проведите ретроспективу, посмотрите что получилось, что нет. Определите как улучшить процесс разработки. И, да, еще раз, это применяется не только в Scrum, но и в других методологиях. Например, PDCA вообще можно применять при любой методологии.
                                • 0
                                  Проблема в непроработанности и непродуманности ТЗ.
                                  Проще всего её решить, разрабатывая ТЗ одновременно с дизайнером и программистом.
                                  И прежде, чем что-то делать, каждый расскажет, как он это понял и какие есть дополнительные мысли на этот счет.
                                  • 0
                                    Спорщики — неудобные люди для начальства, таких не любят, поэтому большинство смирилось и старается не высовываться, кому нужны конфликты? «Мне сказали, я сделал, зарплату получил и хорошо» — вот так думает наш среднестатистический современник. Такое отношение освобождает вашего программиста от ответственности и головной боли, переживаний за то, что кто-то его работу ставит на костыль. «Спрячь сайдбар для одной страницы» — ну разве это не странная идея? Придет ли подобное в голову программисту? Вот он вас и не понял. Почему надо прятать этот сайдбар для одной страницы? Задайте себе этот вопрос. Может быть в будущем у вас появится вторая подобная страница, для которой вы захотите спрятать этот сайдбар? Ну и так далее, по вашей книге!
                                    • 0
                                      Вы двигаетесь в правильном направлении — чем точнее описана задача, тем меньше багов будет в последствии и тем меньше нужно будет переделывать.
                                      На основании своего опыта могу сказать, что вам все же надо стремиться к тому, чтобы писать описание к задачам, причем писать его с достаточной степенью детализации. Я считаю, что в вашем случае пробема в «ТЗ устареет еще раньше, чем будет написано» — учитесь писать ТЗ быстро, иначе будете больше времени тратить на правку багов и доработки, чем на новый функционал. Перед распределением задач по разработчикам обязательно обсуждайте задачи с тимлидом, чтобы он мог дополнить это самое ТЗ (Тим лид в свою очередь может привлекать разработчиков, ответственных за тот или иной кусок системы). При передече задачи давайте прочесть ТЗ и обсуждайте детали реализации с исполнителем, дабы убедиться что он все понял и чтобы у него была возможность задать вопрос.

                                      Я работал как в большой компании, где задачи описывались долго и подробно, и там вообще не было ситуаций, когда всплывали недоработки какие-то (кроме супер сложной корзины товаров крупной торговой площадки, где разработка была на полтора месяцв нескольких людей и сложно было все учесть).

                                      Был и в стартапе с недельными/двухнедельными спринтами, где было 2 команды. В нашей команде задачи давались хорошо (достаточно) описанными и проработанными, и переделывать что-то или менять в процессе ничего особо не приходилось. Багов конечно тоже было много, но они были следствием говнокода, доставшегося от начавших проект людей.

                                      В другой команде задачи давались так, что программистам приходилось самим разбираться что и как делать — итог был весьма печален — чуть ли не больше половины времени уходило на правку багов и доработки того, что работает не так, как надо. Как-то раз в нашу команду пришла «срочная» не маленькая задача, но она была плохо проработана, требования менялись на пути, были критичные ошибки в описании workflow по задаче. Скажу, что кроме намного большего количества багов, задача фактически потратила дорогое время кучи народа, только потому, что изначально PM не правильно понял workflow.
                                      • 0
                                        Хорошо хоть плетью не бьют…

                                        Пару раз сталкивался с формулировкой — такая идея была, но программиста, такие сякие все профукали.
                                        Или вот еще из опыта, нужно СРОЧНО запилить анимированую анимацию (как выяснилось потом это был флеш на андроиде), за 100 рублей и 15 минут.

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

                                        В общем если хотите чтобы программисты делали хороший продукт, нужно выдвигать разумные требования и немного знать матчасть, а если не знаете то хотя бы иногда прислушиваться к тем кто знает.
                                        • 0
                                          Основная проблема, из-за которой возникают все остальные — нужно уметь делегировать зоны ответственности между участниками команды. Если каждый будет понимать, за что он отвечает, как его работа влияет на работу остальных участников команды, и что между ними должна быть обратная связь — многие проблемы будут отпадать сами. Также, весьма необходимо наличие тимлида, человека, который был бы связующим звеном между непосредственными исполнителями задач в команде. Ну и, само собой, нужно пытаться разбивать итерации в разработке на более мелкие этапы, и по окончанию каждой итерации смотреть, что в итоге получается, чтобы вовремя остановить процесс работы в неверном направлении (если так происходит).
                                          • +1
                                            Как же это все знакомо…

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.