Плюсы и минусы заказной разработки без ТЗ



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

    Самые нетерпеливые могут пропустить повествовательную часть и сразу перейти к выводам, для всех остальных… расскажу поучительную историю.

    Начнем с того, что из-за неуверенности в принципиальной возможности решения задачи и способах её решить, у заказчика не было понятного алгоритма достижения желаемого результата. Проще говоря, он хотел, чтобы макеты сами нарезались, сохранялись, располагались на раскроечном столе. Но не имел критериев, что результат соответствует его требованиям. Вот этих самых требований и не было. На самом деле все необходимые данные были, но передавались между сотрудниками из уст в уста и не были зафиксированы документально. Вопрос решился большим совместным Skype-совещанием с последовательной демонстрацией работы дизайнеров в обеих программах. Решено было написать два отдельных скрипта. Один, для экспорта данных о геометрии макета в XML, для Автокада на лиспе. Второй, для генерации шаблона макета и последующей нарезки, на JavaScript для Фотошопа. Была сформирована блок-схема работы с описанием ключевых моментов, которая играла роль ТЗ. Все так хорошо начиналось.

    Кстати, для написания скрипта в Автокаде была установлена пробная версия на 30 дней. Оказалось, что автокад невозможно купить через интернет и нужно идти к официальному дистрибьютору. Фотошоп был куплен с помесячной оплатой.

    Дальше наступили зимние каникулы, согласование сроков и стоимости, предоплата… В общем, всякая скукота с точки зрения программиста. Но отсутствие четкого ТЗ уже тут сыграло свою роль. Об этом чуть позже.

    В общем, когда приступили непосредственно к работе, закончился пробный период Автокада. Была предпринята еще одна попытка купить подписку на автокад на квартал. Но она опять разбилась о физическую доставку в срок от 7 до 14 дней. Этот вопрос не относится к теме ТЗ, но очень уж хочется кинуть камень в сторону Autodesk. Пришлось поставить пробник предыдущей версии.

    Что касается задачи в рамках Автокада — тут была кристальная ясность, благо дизайнер заказчика самоотверженно помогал и отвечал на все вопросы. Определились, как отделить зерна от плевел (детали от описательной части). Код был написан буквально за пару часов. Ау, autodesk, а вы хотели заставить нас ждать 2 недели. Мы все еще пребывали в эйфории, как все хорошо складывается.

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

    После первого релиза выяснилось, что некоторые макеты никак не хотели нормально формироваться в Фотошопе. После анализа XML выяснилось, что некоторые детали состоят из нескольких не связанных между собой линий. Соответственно, они воспринимаются программой как отдельные детали. Если бы было ТЗ, можно было бы сказать, что по условиям на входе мы имеем деталь, ограниченную одной замкнутой полилинией. А так пришлось договариваться. В итоге написали метод, объединяющий выделенные отрезки в одну деталь. Легко отделались конечно. Но час времени на программирование и еще сколько-то до этого на поиск причины потратили. А если бы заказчик уперся и сказал, что поиск детали это наша проблема и дизайнер ничего выделять не будет… Вот тут бы мы попали на перебор линий, поиск пересечений, решение T-образных пересечений и совместное использование одной линии в двух соседних фигурах. В общем, тоже решили бы, но цена была бы для нас совсем другой. Отсюда вывод: ТЗ — ваш лучший адвокат.

    Дальше — больше. Несмотря на то, что документ формируется по заранее обговоренным требованиям, заказчик не очень то доверял программе. Поэтому настоял добавить в нее проверку на соответствие документа требованиям перед резкой. Видимо, опасался, что дизайнер мог поменять параметры документа в процессе оформления. Этого тоже не было в изначальной договорённости. Задача показалась пустяковой, и мы решили пойти навстречу клиенту. В результате некоторых неожиданностей и нездорового перфекционизма, написание проверки заняло 4 часа. Отсюда очередной вывод: ТЗ защитит вас от вас самих, ну или хотя бы поможет попросить за это добавочные деньги.

    Самый важный и самый дорогой урок был получен в самом конце, хотя корни его в самом начале. На этапе формирования договорённости в переписке «пролетал» документ, поясняющий как деталь нужно располагать на раскроечном столе. Сопровождался он фразой «это для общего сведения, вам скорее всего не потребуется». Вот на это «скорее всего» и нужно было обратить внимание. Документ был сделал в Word и на каждом новом компе расползался как ему было удобно. Понять, что именно там было нарисовано, оказалось очень сложно. В итоге мы прочли пояснение как «вам не потребуется». На самом деле суть этого чертежа сводилась к тому, что дизайнер может по своему усмотрению расположить деталь вдоль одной из граней материала. И пара типовых примеров. Естественно, все что не должно случиться, обязательно случается. Поэтому главный вывод: описывайте в ТЗ самый невероятный вариант и стоимость его решения. Возможно, заказчик предпочтет сделать это вручную.

    К чему я это все пишу? А к тому, что работа без ТЗ имеет как кучу минусов, так и несколько плюсов, главное — быть готовым ко всему.

    Минусы:


    • Большая степень неопределенности. Если вы привыкли следовать четким инструкциям, а не придумывать решения на ходу — тогда требуйте детальное ТЗ;
    • Высокая вероятность «лишней» работы. Придуманное на ходу решение может не понравится заказчику. Если у вас нет его подписи под этим решением, то часы, а то и дни вашей работы могут отправиться в мусорку;
    • Неопределенные сроки. Ведь постоянно появляются новые задачи и правки. Надеюсь, хоть аванс вы взяли? Кто знает, удастся ли закрыть проект;
    • Все знают поговорку «время-деньги». Но время может получиться неопределенным. А подписались вы наверняка на какую-то конкретную сумму. Так можно и в минус выскочить;
    • Большинство из нас — люди увлекающиеся, в том числе и работой. Четкое ТЗ убережёт вас от чрезмерного рвения;
    • Клиент не ценит «подарки». Любые работы сверх того, что вы изначально планировали сделать, воспринимаются им как должное;
    • Клиент в принципе недооценивает вашу работу. В результате, ваши возражения воспринимаются как желание уклониться от работы.

    Плюсы:


    • Свобода принятия решений. Вы не ограничены жесткими рамками ТЗ. Найденное более оптимальное решение можно и не согласовывать;
    • Ответственность и инициатива. При решении нетривиальных задач решение может прийти в самый неожиданный момент. Если клиент готов довериться вам как специалисту и смотрит только на конечный результат, то отсутствие ТЗ вам на руку;
    • Отсутствием ТЗ можно обосновать повышенную неопределенность и заложить бюджет на всякие «сюрпризы». Но позаботьтесь об этом заранее, после начала работы будет уже поздно;
    • Формирование и проверка ТЗ требует вложения времени и сил до начала основной работы. Отсутствие ТЗ позволяет эти усилия перенести на более поздний срок. Правда, заплатив за это с процентами;
    • Возможность «переиграть» в свою пользу плохо оговоренные моменты. Особенно, если у вас язык работает лучше, чем голова.

    Конечно, перечисленные «плюсы» — это шутка. Я всех призываю не повторять наших ошибок и всегда работать то четкому и внятному ТЗ. Хотите свободы, пропишите это в ТЗ. Ответственность и инициативу впишите туда же. Лучше попросите больше денег за свою репутацию надежного и честного исполнителя, а также за составление ТЗ. Время и силы, потраченные на составление ТЗ, окупятся здоровьем и нервами, сэкономленными на этапе сдачи. Ну а в том, что головы у читателей хабра «варят» отлично, я ни чуть не сомневаюсь.

    Интересных всем проектов и грамотных тех. заданий!
    Share post

    Comments 42

      +1
      Похоже представители Autodesk еще не спят :-)
        +7
        Пробные версии надо ставить на виртуальную машину. Кончился пробный период — снёс виртуалку, распаковал из архива чистенькую и намазал снова.

        А вообще, ТЗ должно быть, но не должно быть чрезмерно формализованным. Так останется некоторая свобода — правда, для заказчика тоже.

        ПерфекционизЪм — штука такая… Я тоже им страдаю иногда. Но, потихоньку привыкаю не увлекаться. Ибо то, что ты готов засунуть бонусом (просто потому, что оно добавляет удобства для юзера, но почти не создаёт геморроя разработчику) — не нужно засовывать. Нужно тонко намекнуть, что это возможно. А, поскольку этого не было в изначальном ТЗ — заказчик может получить это за дополнительную плату :)
          0
          Желание отбросить формализм и приступить к работе и приводит к отсутствию ТЗ. Честно говоря скрипт для автокада был написан за долго до подписания договора и оплаты аванса, в пылу изучения лиспа и попыток понять, что вообще в нем можно сделать. :)
            0
            Ну вот я наелся этого — когда хотелки возникают в процессе. Важно уметь культурно это отсечь, чтоб заказчика не обидеть.
            В нашем случае часто хватает сказать «напиши мне на мыло, что ты хочешь». А то бывают такие — сегодня ему сделай, завтра исправь, послезавтра верни — а потом с него хрен денег стрясёшь за работу в однократном размере, не говоря уже о тройном.
            А эта фраза рубит ~80% хотелок на корню. Какие остаются — получаются чуть более детализированными: хочу вот это и вот так. И пыл остужает: есть письменный запрос, есть выполненная работа — значит, получишь счёт. Проза жизни, конечно, но желание покушать и прочее никто не отменял. Да и поездки к заказчикам денег стоят, пусть и конторе — но контора деньги не печатает. А жаль :)
          0
          Тут дело не совсем в ТЗ, нужно было с усложнением задач сразу обсуждать увеличение вознаграждения и вы бы остались довольны этим проектом.
            +1
            На самом деле лично я от проекта в полном восторге, честное слово. И думаю контора наша тоже не в накладе. Просто это был первый опыт разработки когда все объяснялось буквально на пальцах, передавалось как былины и предания, а результаты передавались со словами «это то что вы ожидаете?».
            Отличная авантюра получилась, но только благодаря адекватному заказчику.
            +1
            Или ТЗ, или контракт на «аренду команды» за фиксированную стоимость в месяц, и тогда «за ваши деньги любой каприз, любые переделки».
              0
              Тоже вариант. Но фактически это просто перекладывание ответственности на заказчика, понятности это не прибавит.
                +1
                Заказчик, в любом случае, должен нести ответственность за свои прихоти. «Любой каприз за ваши деньги» :)
              +3
              Из моей практике как заказчика так и исполнителя:

              Нет ТЗ — нет фикса за весь проект.
              Иначе в итоге обе стороны будут недовольны

              Остается 2 варианта:
              1. Почасовая оплата
              2. Оплата по итерациям

              Вариант 1 предпочтительней для исполнителя.
              Вариант 2 предпочтительней для заказчика.

              Лучшим вариантом на мой взгляд является второй с разбивкой по задачам и проставленными сроками по каждой.
              Это позволяет заказчику самому формировать пул задач и расставлять приоритеты согласно business value.

                0
                Кстати, отличные варианты. Приму на вооружение. Спасибо.
                  +1
                  Почитайте про agile что-ли
                    0
                    agile практикуем, но больше для внутренних проектов. Не всех заказчиков удается убедить работать по такой схеме.
                      0
                      Значит не так убеждаете )
                      Agile это в первую очередь выгода для заказчика.
                    +1
                    И кстати не забываем просить заказчика оплатить время потраченное на оценку и доработку задач.
                    0
                    2. Оплата по итерациям
                    Вариант 2 предпочтительней для заказчика.

                    Да ничего подобного.
                    Это оставляет риски, что на середине проекта не получится договориться с исполнителем и проект окажется не завершенным.
                    Не завершенный проект — это почти всегда выкинутые на ветер деньги без результата.

                    К сожалению, сам был в такой ситуации, причем на месте исполнителя.
                    Заказчик описал задачу, я оценил ее и мы договорились о сроках и стоимости.
                    Когда я ее закончил, оказалось, что это был первый этап, а второй(мелочь по мнению заказчика) — только предстоит.
                    Вот только оказалось, что задача совершенно за рамками моей специализации(написание драйвера, хотя первоначально задача касалась только компьютерной графики). Я согласился попробовать, но предупредил, что задача для меня новая и я не уверен что справлюсь. Предоплату за вторую часть не брал, естественно. В итоге понял, что за разумные сроки с написанием драйверов такого уровня не разберусь и отказался от исполнения.

                    Что же имеет заказчик в итоге? Он имеет систему, которая не решает задачи для которых создавалась.
                    Он в итоге наверняка не удовлетворен сотрудничеством со мной(хотя эта тема никогда не поднималась, но наверняка это так).
                    Я чувствую себя виноватым, хотя уже год прошел(по факту вины моей нет, я изначально на совершенно другую задачу подписывался).
                      –1
                      Кстати, если кто-то шарит в эмуляции мыши(нужно отлавливать нажатие мыши на экране на кнопку и двигать курсор. сложность в том, что само нажатие на кнопку не должно генерировать мышиных событий. это нужно для эмуляции мыши через тач интерфейс) — напишите в личку, я вас сведу с этим заказчиком. Возможно ему задача еще актуальна. А мне груз с плеч.
                        0
                        А как нажатие на кнопку не должно генерировать мышиных событий?
                          0
                          Мышиный курсор не должен перемещаться на саму кнопку. При нажатии он должен оставаться на месте.
                          То есть игра на которой все это запущена не должна вообще видеть реальную мышь или тач интерфейс.
                          Все события ей должны от самописной системы приходить.
                            0
                            Покер бота что-ли пишите? Откуда такие ограничения? :)
                              0
                              Эмуляция клавиатуры и мыши через тач интерфейс.
                              Для работы с играми использующими клавиатуру и мышь на планшетах, где клавы и мыши нет, а есть только тач.

                        0
                        Да ничего подобного.
                        Это оставляет риски, что на середине проекта не получится договориться с исполнителем и проект окажется не завершенным.

                        Единственный вариант как убрать этот риск — оплата за весь проект по результату.

                        Интересна формулировка что должно быть на выходе после второго этапа, когда было непонятно что это драйвер.

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

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

                        Например мне сейчас пишут прототип игры на юнити. И я четко понимаю что
                        1. Возможен вариант когда придется переписать на UE4
                        2. Логику запросто придется поменять
                        3. Вообще придется отказаться от проекта.

                        И эти риски я закладываю как заказчик.
                          0
                          Изначально речь о втором этапе вообще не шла.
                            0
                            Ну тем более :)
                      +2
                      Я бы не согласился, что наличие четкого ТЗ уменьшает степень неопределенности и бесполезной работы. ТЗ делает более прочной позицию разработчика в спорных моментах, и дает правовую основу, чтобы брать деньги за дурную работу. Чтобы избежать неопределенности и бесполезной работы, ТЗ должно не столько четко описывать каждый чих в программе, сколько адекватно отражать потребности заказчика. А для появления на свет такого ТЗ нужно либо чтобы у заказчика был проджект-менеджер, который отлично знает предметную область и умеет писать ТЗ, либо чтобы исполнитель сам отлично знал предметную область, и мог бы угадать потребности заказчика. Если этого не будет, то работа по ТЗ будет выглядеть примерно так же, как и без него. «Ой, да, действительно, мы согласовали такой вариант, но мы тогда не учли, что… поэтому давайте внесем изменения в… ».
                      В моей практике был случай, когда заказчик утвердил ТЗ, в указанный срок получил готовый продукт, и оказалось, что это вообще не то, что он хотел. Просто потому, что какой-то менеджер поставил свою подпись, вообще не читая ТЗ, а во всех остальных инстанциях решили, что предыдущий согласовывающий всё проверил.
                        0
                        Согласен, наличие ТЗ не панацея. В этом и состоит основная трудность — вытянуть из заказчика его представление, его потребности, его требования и по ним спроектировать продукт. Собственно формирование «правильного» ТЗ соответствует этапу проектирования.
                        • UFO just landed and posted this here
                      • UFO just landed and posted this here
                          0
                          Я сразу сказал, что плюсы это шутка, «вредные советы». К сожалению сам «наелся» подобных ситуаций что описана в вашей статье.
                          0
                          если клиент плохо представляет, что получит — он не оценит, что получил от вас больше

                          Золотые слова. Сторонникам подхода «а давайте напишем универсальный расширяемый код» посвящается.
                            0
                            Мы(сторонники подхода «а давайте напишем универсальный расширяемый код») в первую очередь пишем такой код не для того, чтобы клиент рад был. А для того чтобы потом самим было проще его поддерживать и расширять.
                            • UFO just landed and posted this here
                                0
                                В принципе, даже для разовых заказов имеет смысл такой код писать.
                                Ведь то что пишешь для одного проекта можно потом использовать и в другом.
                                  +2
                                  И ни что не заменит радости от ощущения качественно сделанной работы.
                                    +2
                                    Я в разработке уже тыщу лет, работал и на заказ, и для in-house, сделал многие десятки проектов. Делал и по нескольку в одной команде, и в разных. Это предпредисловие :)
                                    Ведь то что пишешь для одного проекта можно потом использовать и в другом

                                    Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
                                    Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
                                    Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:

                                    1. Когда ты продаешь решение, которое потом будет частью большого проекта. Пример — CMS.
                                    2. Когда ты продаешь проект, который является долгосрочным, и однозначно уверен, что он будет дорабатываться. Если уверен!

                                    Это было предисловие.

                                    В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
                                    Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
                                    Как-то так.
                                      0
                                      Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо

                                      У меня наверно процентов 80 кода с минимальными изменениями кочует между проектами. Вплоть до того, что это все оформляется в некий фреймворк, который везде и используется.
                                      Может быть у меня задачи такие(разработка игр)… Хотя я рыпался в совершенно левые области ради развлечения(разработка терминалов, например) и там реюз кода также был на уровне 80%.
                                      Единственное что не поддаются реюзу — это собственно логика самого приложения. Взаимодействие объектов и прочие мелочи.
                                      Но в любом проекте с которыми мне приходилось иметь дело(начиная от мелких тетрисов и заканчивая системами работающими в кластере) — логика это мизер. А вся основная работа делается кодом, который можно использовать много раз.
                                        0
                                        Наверно, если я буду каждый раз браться за совершенно новую задачу: сегодня игра про колобков, завтра веб сайт интернет магазина, после завтра клиент-банк, после-после завтра система видеонаблюдения — у меня тоже не будет реюза…
                                        Но, собственно, с чего мне дергаться между разными областями, если я специалист в одной и могу эффективно внутри этой области решать задачи, в частности за счет огромной кодовой базы собранной на предыдущих проектах.

                                        В качестве послесловия: в этом году 10 лет как фрилансер.
                                          0
                                          Игры — да. Движок, который используется потом в десятках других игр и бизнес-приложение, каждое из которых суть другая разработка — разные вещи.
                                          Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
                                          Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
                                          Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
                                            0
                                            Кстати, Ваши наработки для игр — это частные решения, которые становятся частью большого решения — фреймворка. И его тоже очень условно можно назвать CMS :)
                                              0
                                              Ну чтобы уж не быть голословным — давайте конкретную задачу, которая не может сгенерировать код приемлемый для использования в другой задаче. Мне как-то не верится, что вообще в природе бывают такие задачи, которые на 100% уникальные. Да даже на 50% в уникальность не могу поверить. Так что буду благодарен за пример.
                                                0
                                                Вставлю свои пять копеек. Я всегда пытался писать код который можно использовать повторно, старался запроектировать с запасом, но почти никогда не использовал прошлые наработки. Просто потому, что через 2-3 месяца я банально забывал где я это писал и как это нужно использовать.
                                                Ну а то, что мне казалось, что я стал умнее и могу лучше, даже упоминать не стоит.
                                                Хотя написанный в 2005 году велосипед-CMS использовал лет 7, правда в php-код я почти не лазил, собирал из изначально написанных блоков. Но это исключение.
                                                  0
                                                  Переписывание, рефкторинг — это понятно.
                                                  У меня тоже не очень много кода, который без изменений прожил десяток лет(хотя и такой есть).
                                                  Но речь именно о том, чтобы брать решение и возможно слегка его модифицировать — использовать его.

                              Only users with full accounts can post comments. Log in, please.