Техническое задание: почему формулировка «Сделать как здесь» не срабатывает?

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

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




    И представим себе ситуацию: есть менеджер (аналитик) Маша, исходя из потребностей заказчика Иван Иваныча (ИИ) соорудившая некое техническое задание (ТЗ) для программиста Васи, в котором сказано что-то вроде «Взять функционал из места A системы X и повторить его в месте B (системы Y)». Иначе говоря — «Сделать как здесь», без подробного описания всех технических деталей реализации.

    Такая ситуация несет в себе огромные риски.

    Первое: программист Вася может неправильно понять ТЗ и при отсутствии привычки Васи задавать вопросы, а также постоянного контроля со стороны Маши или непосредственного начальника Пети сделать полную фигню. Если Вася является типичным программистом — это с определенной степенью вероятности может произойти.



    Второе: в случае, если Маша / Петя все-таки «держат руку на пульсе», а непонимание ТЗ Васей все-таки вызывает у него ряд вопросов к Маше и Пете. В лучшем случае Маша, Петя и Вася в итоге как-то худо-бедно договорятся и в итоге, истратив немеряное количество нервов, сломав десяток копий, съев пуд соли и получив дюлей от ИИ за срыв сроков, все-таки посредством Васиных натруженных до мозолей мозгов реализуют функционал, более-менее или даже полностью соответствующий требованиям заказчика.

    Наступит очевидное и недолговечное счастье для всех. Вася будет играть в любимый Counter Strike, Маша — делать карьеру, Петя — всецело и без остатка отдаваться общению с семьей и поездке в Турцию, а ИИ как настоящий капиталист — считать прибыли. Ровно до тех пор, пока реализованный функционал не потребуется существенно изменить/переделать. И тогда наступает новый виток разбирательств в недокументированном коде, непродуманной архитектуре, попыток все переделать. В общем, обыкновенный трудовой процесс настоящих трудяг от IT. Месяцы и годы, потраченные на это, не считает никто, кроме, может быть, жен программистов.



    Третье: если Вася по каким-либо причинам «уперся» (например, у него возник личный конфликт с Машей или Петей на почве психоэмоционального стресса, вызванного общим переутомлением и состоянием аффекта от увиденного кода или же просто авральным зарабатыванием денег на ипотеку), либо в компании дела обстоят не очень, или Маша (или Петя, или Вася — неважно) преследуют какие-либо личные цели (например, выдвижение Маши в ведущие аналитики, которого она добивается всеми доступными способами, включая совсем уж неэтичные), либо по еще каким-либо причинам — в этом случае все может обернуться плохо: как для Маши/Васи/Пети, так и для заказчика/системы в целом. Копий сломано будет еще больше, про нервы, репутацию и общее отношение я даже не говорю; а соли будет съеден уже не пуд, а целый КАМАЗ. Про сроки выполнения задачи вообще речи нет. И это при условии, что никто не уйдет, плюнув на все это (или его не «уйдут») и задача/проект вообще не будет загублен.



    Ситуация потенциально не выгодна никому: ни Васе, ни Маше, ни Пете, ни ИИ и его бизнесу в целом. Но, тем не менее, такое происходит довольно часто и повсеместно.

    Вопрос: что делать, чтобы не попасть в такую ситуацию?



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

    Маше: Работать на развитие. Причем не только собственное. Несмотря на все стремление делать карьеру, все-таки в подробностях описывать все технические детали предстоящего ТЗ. Менеджер/аналитик, не разбирающийся (или не желающий разбираться) во всех технических тонкостях — априори не есть хороший менеджер/аналитик; тут, скорее всего просто стремление сделать карьеру, и ничего более.

    Пете: Работать на развитие. Улучшать архитектуру системы. Вникать в то, что именно делает Вася. Не позволять плодить говнокод плохо — ни Васе, ни Маше, ни даже ИИ. Вникать в то, чего хочет ИИ и чего хочет Маша. Иногда это разные вещи. :) Выделить Васе один день в неделю, который он будет тратить на улучшение интерфейсов, оптимизацию кода, выкашивание багов, etc. И при этом не слушать ни Машу, ни ИИ, если они пытаются программиста в указанное время у него «отобрать».

    Васе: Работать на развитие. Заниматься не только задачами, которые ставит непосредственное начальство на работе: изучать (или даже написать) какой-нибудь интересный фрэймворк, создать интересный сайт или сервис, вести блог. Быть в курсе современных тенденций в IT и не зацикливаться. Выйти из «зоны комфорта». И иногда думать не как программист, а как менеджер, аналитик, Петя, Маша, ИИ и сам Лысый Черт вместе взятые. Задавать вопросы, в том числе самому себе. Если крыша не поедет.



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

    Комментарии 19

      0
      Жили они долго и счастливо и померли в один день.
        –1
        Именно. :)
        +2
        Пишите хороший код, а плохого вовсе не пишите (с)
          0
          Эх… если бы все дело было только в коде…
          +2
          В создании сайтов «сделайте как здесь» чаще всего означает, что клиент абсолютно не хочет задумываться над функционалом и ему кажется, что «как здесь» решит поставленные задачи. И чаще всего ошибается.
          Как вообще можно работать с человеком, который не готов описать, что ему нужно и зачем?
            –1
            Да, есть такое. Но самая жесть начинается, когда «сделать как здесь» звучит из уст не заказчика, а менеджера проектов или аналитика. И, по собственному опыту, как правило за этим стоит либо просто нежелание разбираться, либо карьеризм и интриги — это в самом плохом варианте. При этом PM прекрасно понимает «что и зачем».
              0
              с карьеризмом в таком виде не встречался, а вот нежелание разбираться — самая частая причина, по моему опыту
                0
                > с карьеризмом в таком виде не встречался

                повезло…
            +1
            особенно «доставляет» когда ты пишешь Х, а тебе говорят сделай как в 1С…
              +1
              Переменные русскими буквами?.. :)

              У меня лет 8 назад был такой случай: один товарищ в конторе любил в коде переменную называть матерным словом. Правда, это было не в 1С, а в VB/VBA, но не суть… Каким-то образом это дошло до начальства — был скандал, приказали искоренить. :) А поскольку товарищ писал много и очень плодовито, то на рефакторинг всего этого хозяйства ушло без малого месяц.
              0
              Ещё бывает кроме «сделать как здесь», «а как сейчас?»
                +1
                Ага. И еще «как было раньше», «сами не знаем как» и «чтобы все работало».
                  0
                  «А как сейчас» априори задача совместная — аналитика и программиста. Но отвечает за нее, как правило, в бОльшей степени все-таки аналитик (Project Manager), и от того, насколько качественно он понял и «разрисовал» задачу, по сути, зависит весь проект.
                  0
                  Самое «интересное» начинается тогда, когда ты сделал «сделай очень быстро вон как у Петровича, но чтобы сверкало» и забываешь про этот говнокод «на скорую руку». А потом через пол года-год: «Помнишь ты делал одну штуку для нас, там надо добавить колёсики и что бы всё выгружалось в Excel». А ты уже и забыл как там и что после десятка таких же «хотелок» начальства и снова погружаешься в свой говнокод… печалька.

                  Не знаю как в остальных конторах, но у нас именно так большинство проектов делается.Времени на то, чтобы подумать «а как было бы лучше» нет.
                    0
                    Эволюционный рефакторинг Файулера читайте. Там рассказано, что делать в таких случаях
                    +1
                    Вообще нет проблемы сделать «как здесь», просто нужно сразу брать деньги за аудит делать опись функционала под подпись. Оценивать именно то, что вы записали. Вообще обычно вопрос бывает не «сделайте как здесь», а «сколько примерно стоит как здесь». В этом случае клиент все правильно делает, он же не знает сколько это стоит. Ему надо прикинуть, посчитать, стоит ли овчинка выделки. А истеричные Васи и Пети — это уже фантазии ваши.
                      0
                      К сожалению, не фантазии, а суровая и вполне такая ощущаемая (сейчас — уже в прошлом) реальность, где зачастую не работает ни «под подпись», ни «добрыми словами»… С точки зрения заказчика все правильно. С точки зрения аналитика в данной ситуации — нет.
                      +1
                      Мне кажется, для автора это несколько больная тема. Но можно найти довольно много примеров, когда постановка задачи «как там» вполне работает.
                      Не то, чтобы это лучшая практика, но… довольно много продуктов, например, перешли в опенсорс, потому что разработчики взяли платный продукт и переписав его с нуля, реализовали «как там». И никто из них не жаловался, что нет спецификации.

                      Когда есть образец, то это очень и очень хорошо, т.к. его можно исследовать и получить информации гораздо больше, чем в самой подробной спецификации.

                      Риски же, о которых писал автор, все лежат в области что продукт получится не такой, как его задумал владелец продукта. И, наверно, если ВП согласен принять такие риски, то задача «сделать как там», вполне себе имеет место на жизнь.

                      Тем более, что все остальные аргументы про быдлокод в самой статье, как мне кажется, ни какого отношения к теме не имеют, и имеют аргументацию вида:
                      1. Ой, а придется же потом переделывать если мы поняли не так. (я чаще видел переделки, когда писались САМЫЕ ПОДРОБНЫЕ СПЕЦИФИКАЦИИ, чем когда они не писались вовсе).
                      2. Ой, в команде может возникнуть психологическая несовместимость/усталость/конфликт. (Ну может. А может и не возникнуть или возникнуть по любой другой причине.)

                      Вывод:
                      1. Если продуктаунер и/или заказчик в команде или оплата у вас идет за время, то такая «спецификация» — довольно неплохой вариант.
                      2. Если же ваша команда работает за оплату результата, то любой вариант с отсутствием документального и подробного ТЗ — глупость, и как именно вы получили задание — не имеет значения. Все варианты без письменной договоренности — одинаково плохи.
                        +1
                        Да, Вы правы — тема несколько больная… в свое время не повезло, насмотрелся на разного рода «эффективных менеджеров» сполна.
                        А про риски и спецификации Вы хорошо написали.

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

                      Самое читаемое