Pull to refresh

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

Reading time 5 min
Views 35K


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

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

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

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

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

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

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

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

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

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

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

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

Минусы:


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

Плюсы:


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

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

Интересных всем проектов и грамотных тех. заданий!
Tags:
Hubs:
+11
Comments 42
Comments Comments 42

Articles