Как составить грамотное Техническое задание для работы над интернет-магазином OpenCart?

29.03.2018 17:29 (459 просмотров)

ТЗ должно быть!

Я сам неоднократно начинал работу под честное слово. И всегда это превращалось в мозготрепку. Потом я начал писать ТЗ, и описывать в нем четкие условия завершения работы. Но это занимало много времени. И пока его сделаешь от начала и до конца, заказчик вовсе может "слететь". Но опять, же, слетают, в основном те заказчики, кто вообще не хочет включать мозг и думать наперед. Поэтому лучше потратить 2 дня на ТЗ и потерять клиента за это время, чем получить клиента мгновенно и работать на него месяц (хотя рассчитывал 2 недели).

 

Сначала думай, а потом называй цену и делай, а не наоборот!

Когда загоняешься сразу в работу, не успеваешь осознать суть того, что на самом деле хотел получить клиент и сколько это на самом деле должно стоить. В итоге делаешь ровно то, что соответствует озвученному бюджету. И в итоге клиент не доволен.

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

 

ТЗ должно соответствовать и Вашему уровню, и уровню клиента

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

Когда ты спрашиваешь клиента: "У Вас есть брендбук?", - а он отвечает: "А что это такое?", - то лучше пропустить остальные умные слова.

Лучше спросите его: "Для чего Вам нужен интернет-магазин? Вы планируете давать рекламу и вкладывать деньги в его продвижение? Или просто пусть он будет, чтобы постоянным оптовым клиентам было удобно оформлять заказ без этих вот диктовок артикулов по телефону?"

 

Не берите на себя слишком много

Инициатива наказуема

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

Если вы видите, что клиент чего-то не знает, вы можете ему предложить. Но обязательно озвучивая при этом цену вопроса.

Занимайтесь конкретным делом

Да, есть такое понятие как full stack developer. Но к нему необходимо приходить со временем (если захочется), а не сразу же. В начале своего пути разработчика лучше выбрать что-то конкретное. Конткретную область ответственности, конкретную систему, с которой вы работаете (и потом узнаете все ее подводные камни)

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

 

Не стесняйтесь торговать!

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

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

Все эти опасения связаны со страхом потерять клиента и неуверенность в собственных силах.

Главное в данном контексте: подумаете, какой нормальный бизнесмен будет экономить на средстве производства? Да никакой! Это было бы равноценно тому, что такисту было бы жалко потратиться на бензин. Поэтому если вам попадается "жадный" клиент, то Вы должны сделать для него только то, что оговорено. Но, чаще всего мы сами включаем цензора в голове. Более подробно суть материального вопроса описана в статье "Сколько я стою как разработчик?".

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

 

 

Ради безопасности

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

Есди делаете сайт с шаблоном, то это должно быть указано. И приведение недостатков шаблона в порядок, (которое часто обнаруживается после запуска, когда клиент обращается к SEO-оптимизатору),  должно быть вынесено за рамки первоначального ТЗ по созданию и запуску сайта.

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

 

4 совета из книги "Идеальный программист"

Лично мне здорово помогла книга "Идеальный программист" Роберта Мартина, котороую рекомендую прочитать всем веб-разработчикам, если кто ее еще не читал.

1) Если вы хотите повысить свою квалификацию как разработчика, всегда помните: заказчик постоянно увеличивает объем работы.

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

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

Вот часть "откровений" того программиста:

Ключевые участники проекта (будь то внешний за-

казчик или внутренний руководитель) придумали схему, которая заставит

разработчиков быстро писать код. Эффективно? Нет. Быстро? Да. Вот как

работает эта схема.

 

– Сказать разработчику, что приложение очень простое. Это создает

у группы разработки искаженное представление о масштабах работы.

Кроме того, разработчики быстро берутся за работу, а тем временем…

 

– Функциональность проекта расширяется, причем рабочая группа ока-

зывается виноватой в том, что не распознала эту необходимость за-

ранее. В нашем случае жесткое кодирование контента должно было

привести к усложнению обновлений. Как я мог этого не понять сразу?

Я понял, но до этого я получил лживые обещания от заказчика. Или

другой вариант: заказчик нанимает «нового человека», который на-

ходит какое-нибудь явное упущение. А завтра заказчик скажет, что

они приняли на работу Стива Джобса, и в приложение нужно доба-

вить алхимические трансформации? Далее…

 

– Проект постоянно подгоняется, чтобы работа была завершена к ис-

ходному сроку. Разработчики трудятся на максимальной скорости

(и с максимальным риском ошибок, но кто станет обращать на это

внимание?). До срока остается пара дней? Зачем говорить, что срок

сдачи можно перенести, если работа идет так продуктивно? Нужно

использовать это в своих интересах! Потом срок наступает, добавля-

ется еще несколько дней, потом неделя — и это после того, как вы

отработаете 20-часовую смену, чтобы все было сделано вовремя. Все

как на знаменитой картинке с ослом и морковкой — не считая того,

что с ослом обращаются намного лучше, чем с вами.

 

Вот как комментирует эту же ситуацию Роберт Мартин.

Они хотели иметь приложение для iPhone к «черной пятнице». Они

были готовы заплатить за него. Они нашли кого-то, кто возьмется за

эту работу. Так в чем их винить?

 

Это Джон согласился на исходный двухнедельный срок, отлично зная,

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

 

Это Джон работал по 20 часов в сутки и по 90 часов в неделю. Это Джон отказался

от своей семьи и нормальной жизни, чтобы не сорвать срок сдачи.

 

Короче говоря, Джону захотелось быть героем. Он увидел шанс добиться славы

и ухватился за него.

 

Профессионалы часто совершают героические дела, но не потому, что

хотят быть героями. Профессионалы становятся героями, когда они

хорошо выполняют свою работу, без нарушения сроков и бюджета.

 

МОРАЛЬ

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

    ( Иногда несчастный модуль, который, по идее, должен устанавливаться за 30 минут, в действительности нужно устанавливать и настраивать 2 часа, а потом еще 2 дня переделывать код шаблона, чтобы этот модуль заработал... Поэтому, когда Вы не знакомы с модулем, который просит заказчик, Вы не должны говорить ему цену и сроки на основании опыта с другими модулями. Вы должны сказать: "Я не имел дела с этим модулем. По идее, он устанавливается стандартно и оплата за это будет стандратная. Но, если я его установлю, а он работать не будет, то естественное, что надо будет либо покупать еще какой-то модуль, либо искать проблему. В общем, если он вдруг не пойдет, тогда будем думать"
  • Не надо пытаться!

    ( Речь идет о том, чтобы попытаться выполнить нереальную задачу за счет переработок и недосыпа, только бы заказчик был доволен. Или как вариант для самоучки: только бы не спалили, что я не очень крутой программист... )

    Обещая «попытаться», вы признаетесь в том, что ранее вы сдержива-

    лись; что у вас остался дополнительный резерв, которым вы можете

    воспользоваться. Вы признаетесь в том, что цель может быть достиг-

    нута посредством приложения дополнительных усилий; более того,

    вы фактически обязуетесь применить эти дополнительные усилия для

    достижения цели. Следовательно, обещая попытаться, вы обязуетесь

    добиться успеха. Тем самым вы взваливаете на себя тяжелое бремя.

    Если «попытка» не приведет к желаемому результату, это рассматри-

    вается как провал.

  • Если вы не справились

    Что ж, бывает. Могло произойти что-то непредвиденное — жизнь есть

    жизнь. Однако вы не должны подводить тех, кто от вас чего-то ожидает.

    В такой ситуации лучше как можно скорее изменить ожидания.

     

    Если вы не можете выполнить свое обещание, очень важно как можно

    быстрее сообщить об этом тому, кому вы обещали.

 

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

НО! Чем больше вариантов правок видит заказчик, тем больше он совменвается какой лучше, и хочет еще вариантов...

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

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

В итоге у Вас будет такой список, что посмотрев в него Вы скажете: "Да тут работы, на отдельный проект с отдельным ТЗ".

 

2) Профессионалы говорят правду облеченным властью. У них достаточно смелости, чтобы сказать «нет» своим начальникам.

 

Рабам запрещается говорить «нет». Наемные работники неохотно го-

ворят «нет». Но профессионалу положено говорить «нет». Более того,

хорошим руководителям очень нужны люди, у которых хватает смело-

сти сказать «нет». Только так можно действительно чего-то добиться.

 

Руководители — люди, которые должны исполнять свои обязанности,

и большинство руководителей знает, как выполнять свою работу на

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

можно более жестко преследовать и защищать свои цели.

 

Программисты — тоже люди, которые должны исполнять свои обя-

занности, и большинство из них знает, как выполнять свою работу на

должном уровне. И если они относятся к числу настоящих профессио-

налов, они будут как можно более жестко преследовать и защищать

свои цели.

 

Когда ваш руководитель говорит вам, что страница входа в систему

должна быть готова к завтрашнему дню, он преследует и защищает одну

из своих целей. Он выполняет свою работу. Если вы хорошо знаете, что

сделать страницу к завтрашнему дню невозможно, то отвечая: «Хоро-

шо, я попытаюсь», вы не выполняете свою работу. Выполнить ее в этот

момент можно только одним способом: сказать: «Нет, это невозможно».

Но разве вы не должны выполнять распоряжения начальства? Нет, ваш

начальник рассчитывает на то, что вы будете защищать свои цели так

же жестко, как он защищает свои. Таким образом вы вдвоем приходите

к оптимальному результату.

 

3) Проблемы вашего работодателя — это ваши проблемы

 

Если вы пишете бухгалтерскую систему,

вы должны разбираться в бухгалтерии. Если вы пишете приложение

для туристической фирмы, вы должны разбираться в туризме. Быть

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

ответственно.

 

4) Преждевременная точность

И бизнесмены, и программисты часто попадают в ловушку преждев-

ременной точности. Бизнесмены хотят точно знать размер прибыли,

прежде чем давать согласие на проект. Разработчики хотят точно знать,

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

стороны желают иметь точную информацию, которой быть заведомо

не может, причем часто они готовы потратить целое состояние на по-

пытки ее получения.

 

К сожалению, на бумаге все выглядит совсем не так, как в рабочей

системе. Когда бизнесмены видят, что получается из реализации их

требований в системе, они понимают, что хотели совсем не этого. А ино-

гда уже после знакомства с реализацией они начинают лучше понимать,

что же им на самом деле нужно — чаще всего не то, что они видят.

Когда вы демонстрируете новую возможность бизнес-участникам,

у них появляется больше информации, чем было прежде, а эта новая

информация влияет на их восприятие системы в целом. В конечном

итоге чем точнее формулируете свои требования, тем быстрее они те-

ряют актуальность в ходе реализации системы.

 

Профессиональные разработчики понимают, что оценки могут (и долж-

ны) базироваться на требованиях с низкой точностью. Они понимают,

что оценка — это именно оценка. Они всегда включают в свои оценки

диапазоны погрешности, чтобы бизнес-участники понимали наличие

неопределенности.

 

В этой книге приводится методика прогнозирования развития событий с 3 разными вариантами:

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