Тз от – Образец формы технического задания по 44 ФЗ 2019

Содержание

эпический опыт конкурсов и пара баек / КРОК corporate blog / Habr


Широко известный пример неточно поставленного ТЗ

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

Однажды мне достался проект, рассчитанный на полтора года с ооочень трудным заказчиком. Статус: прошло полгода, но всё ещё идут согласования технического задания. Подписались на одно, но заказчик упорно продолжал выдвигать новые требования. Задача ставилась даже не закончить вовремя или заработать, а выйти достойно, с минимальными для всех потерями.

Было сложно — не то слово. В длинном перелёте я читал ТЗ на 20 страниц. В нём была такая особенность: если читать его бегло, то может показаться, что оно написано правильно и точно. Но если начать копать в детали инженерной реализации, то всплывало сразу много нежданчиков. Некоторые требования подпунктов, вроде 3.2.5 и 4.8.2.9, могли противоречить друг другу или быть просто взаимно невыполнимыми в реальном мире.

Почему нельзя согласовать ТЗ сразу?

Не секрет, что на конкурсах и тендерах крайне редко встречается достаточно полное техническое задание (или хотя бы детальные критерии приёмки, или просто внятные техтребования). Любой размытый пункт документации может обеспечить вам невероятное количество сюрпризов и увеличение работ на порядок. Вот буквально пара примеров из реальных документов, по которым надо было как-то оценивать объём работ и подписываться:
  • «Система должна обладать интуитивно-понятным графическим пользовательским интерфейсом», — в переводе на русский, это, скорее всего, означает что-то вроде: «Кроме консоли нужен GUI на русском и с большим количеством пояснений, потому что комплексом будет управлять секретарша». Скорее всего. Потому что может оказаться, что у заказчика есть свои представления об интуиции, и он будет настаивать именно на них. Но чаще всего эта фраза типовая для документации и, в целом, не очень опасная.
  • «Система должна обеспечивать простую и гибкую настройку прав доступа пользователя системы», — это уже на порядок хуже. Здесь не описано, какие бывают права, а разница в деталях сетевых ролей может повлиять на архитектуру. И, соответственно, на оборудование, которое нужно в проект.
  • Один раз встретилось после детального описания системы документооборота такое: «Срок хранения информации должен быть настраиваемым по периоду», — попробуйте угадать, что заказчик имел в виду. Вас интересует для начала, о какой именно информации речь и где она будет храниться. С равным успехом это может оказаться как обычная фраза о том, что должен быть доступен архив записей (что очень просто), так и то, что это должно быть резервное копирование на отдельную площадку.

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

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

Что же происходит дальше? Дальше наступает интересное экологическое равновесие.

В плохом случае:

  • Если, увидев огромное внезапно появившееся ТЗ, исполнитель откажется от контракта госзаказчика по своей инициативе, он может быть добавлен в «чёрный список» поставщиков.
  • Заказчик при этом не получит результат, но уже потратит деньги.

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

В итоге все всё прекрасно понимают и договариваются. Конечно, бывают отдельные проекты, где крупный заказчик своим ТЗ может буквально свести с ума интегратора. Только он прекрасно понимает, что если так сделает, больше этот интегратор к нему в конкурсы не придёт. А по многим работам в стране всего 2-3 компании, которые вообще могут потянуть такое, чисто по сложности и объёму проекта. Оставаться в конце один на один с последней страшно, уже исполнитель будет условия диктовать.

Например, вот проект. Была в ТЗ строчка: «Систему надо поставить на мониторинг». Это вылилось в отдельный проект: невозможно было ни оценить трудозатраты, ни спланировать. А заказчик всё видел иначе. У него есть внутренний регламент, исторически сложившийся. Дальше начинаются так называемые «тёрки». С одной стороны: «Мы вам сделаем по ТЗ», с другой — «Мы так не примем». Понятно, что обе стороны в той или иной степени правы, и дело доводить до конфликта не хотят: с одной стороны, повторюсь, суд и «получите, что хотели», с другой — потраченные впустую деньги и время. Никому это просто не надо.

В итоге в других частях ТЗ нам пошли на уступки, и мы поняли, какие точно у заказчика требования. На следующие проекты мы — уже проверенный поставщик — и имеем точную базу для расчётов, без вилок.

Что делать, если совсем плохо

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

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

Где-то решали быстро, где-то предлагали сдавать по их ТЗ и смотреть, что получится. Заказчик увидел, что работы реально идут, согласился, что так правильно, и не давил, пока всё шевелилось. В общем, вырулили.

Личные встречи и выезды

Ещё одно весёлое попадалово — это если заказчик хочет встречаться по каждому чиху. Особенно приятно, когда это нефтянка с Дальнего Востока. В одном проекте была традиция — любую мелочь обсуждали раз в неделю на совещании. Собиралось 12 человек от компании, 5 человек от производителя железа и нас трое. И безопасник. В конце концов, смогли тоже побить на части и перевести на телефонную конференцию. По телефону мужики друг друга не видели, пятнице не радовались, и потому совещания шли в 3 раза быстрее.

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

Опять же, личные встречи нужны, чтобы решать сложные вопросы. Любое серьезное решение или этап — встречаться. По телефону не работает.

Железо

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

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

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

Работа с иностранцами

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

Мы отвечаем за железо, коллеги иностранные — за ПО. Предлагаем им: давайте пропишем чётко, что входит в состав работы, где зона ответственности, сделаем нормальное ТЗ: что делаем, какой результат, чтобы потом протестировать и штатно сдать. Они: «Да зачем это надо? Там же вот описание работ!» — а там документ на две страницы в духе: «Наш профессиональный инженер приедет и всё сделает, не волнуйтесь». И ещё добавили: «У нас на сайте есть описание системы — вот». Подписались они в итоге без детального ТЗ. Внедряли как есть. Систему они реально подписали и закончили только через 2 года (два поколения системы сменилось), специально под этого заказчика дорабатывали часть функционала.

А проблема была в том, что у них всё было заточено под Америку, а в Европе есть свои внутренние стандарты по обработке данных. И в них они не уложились. Заказчик, естественно, стандартную систему не принял. Примерно в этот момент коллеги остро осознали, зачем нужно точное ТЗ. Точнее, что оно нужно им, а не заказчику.

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

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

Альтруизм и отвага

Ещё одна черта, наверное, чисто российских проектов — это «Чип и Дейл спешат на помощь». Редко, но бывают эпохальные вещи, например, прямо к сдаче железо выходит из строя. Но альтруизм и отвага делают нас непобедимыми. Там, где иностранный подрядчик рукой бы махнул и начал бы стандартную замену через вендора, мы можем и на уши всех поднять, и на пороге у их гендира объявиться где-нибудь в Швеции, или ещё хуже — с паяльником залезть в железку и починить. Конечно, бывает, не помогает, но в целом срабатывает. Правда, винтик лишний всегда остаётся.
Регламент заказчика

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

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

Но часто ситуация хуже: состав документации не обозначен, заказчик ссылается на ГОСТ. А там, например, три периода тестирования — предприёмка, опытная эксплуатация, финальная сдача в промэксплуатацию. У некоторых же заказчиков финальная сдача бывает почему-то до опытной эксплуатации, например.

Иногда случается, что заказчик просто ошибается в ТЗ. Привозим оборудование, а его ставить некуда, места просто нет. Что делать? Опять искать компромисс.

План приёмки

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

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

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

В целом

Вообще, ситуация меняется: за последние 8 лет заказчики очень повзрослели, стали серьёзнее относиться к делу. Раньше было вообще без бумаги, даже схему расстановки часто могли не передать. Теперь всё пишется. Мы тоже нахватались грабель, стали сами настаивать, чтобы в проекте была необходимая документация, это ведь и наша защита тоже. Цель — чтобы все всех понимали.

У заказчиков на ключевых должностях появились люди из интеграторов, которые видели процесс с другой стороны. Рынок разросся, за счёт этого культура поднялась. Западные спецы пришли, тоже хорошо понимают, что и зачем.

Но надо сказать, если бы мы предлагали лет 10 назад так, как сегодня работать, нас бы ни один заказчик не стал слушать. Культуры не было, бесполезно. Помню, было даже так в те дремучие годы: программу приёмки подписали. Дошло до дела, заказчик говорит: «Надо иначе». Мы: «Вот документ подписан вами». Он: «Да выкиньте его, нам надо иначе!»

habr.com

как разработчики в такое ввязываются / Habr

Результаты опроса из прошлой статьи меня шокировали. Ведь когда разработчики берутся за проект без ТЗ, умирает один неоперившийся аналитик и 10 маленьких котят. Зачем вы так? Как же так получается?

Почему так происходит? Что можно сделать? Вот несколько версий:

Версия 1: боюсь потерять клиента


Всем знаком этот первобытный страх! Он достался нам в геноме от пещерных программистов! Если я упущу этого клиента, то мне нечего будет жрать!!! Возьмите себя в руки, председатель!

Пока мистер Без ТЗ жрет ваш мозг, за это время можно успеть найти более вменяемых заказчиков, и заработать гораздо больше.

Потеря клиента лишь стимулирует активнее искать новых. Иллюзия, что следующего заказчика придется искать очень-очень долго, развеется, когда вы сконцентрируетесь на оптимизации процесса поиска, технологии выявления наиболее выгодных заказчиков из всего мутного потока. Чем более вы активны, тем больше вас знают, тем больше к вам обращаются сами.

У меня не раз бывало такое, что меня рекомендовал своим знакомым заказчик, с которым мы не договорились. То есть он ушел раздосадованный, а потом бац! рекомендует меня знакомым, партнерам, любовнице… Правда, по таким рекомендациям часто тоже такое себе приплывает…

Нужно понимать, что каждый заказчик немного мазохист, они любят когда с них требуют, отказывают им. В отношениях с заказчиком должен присутствовать едва уловимый BDSM. Если вы ведете себя в духе “что барин изволит?”, то возникают подозрения, а не менеджер ли вы?

Версия 2: для друзей


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

Если хотите делать проектик с друзьями, то окажите им услугу в составлении подробного ТЗ, позаботьтесь о тех, кто вам дорог. При этом нужно понимать, что вы скорее всего рассоритесь еще на этапе написания ТЗ, а то и раньше.

Вот, вам занимательная история одного проекта “по дружбе”. Моему близкому другу надо было срочно и недорого запускать интернет-магазин, потому как инвестор дал “добро”, и контейнер уже плыл из Китая. Я сразу предупредил, что это не совсем моя тема, так как я в основном работаю с корпоративными e-learning продуктами и медицинскими системами, но чего-нибудь придумаем. Итак, инвесторские деньги выделились, и друг проявился в моем поле зрения с бодрым: “Ну, давай портфолио по интернет-магазинам! Мы подрядчика выбираем! Только присылай побыстрее, не затягивай!” Я слегка фаломорфировал о того, как быстро “Спаси-помоги, друг дорогой!” трансформировалось в: “Я пришел к тебе с редкой возможностью поучаствовать в моем тендере!” и слил кореша с формулировкой: “У меня тут заказ на несколько миллионов — сорри, сейчас некогда портфолио по магазинам собирать”. Друг обиделся, но сообщил мне, что я “всё равно в шорт-листе”. На том и порешили.

Версия 3: для себя


Кажется, что вы-то уж точно знаете, чего хотите. Внутри коллектива все должны быть на одной волне, это же командный дух! Поэтому лучший способ рассорить даже самую сплоченную команду — работать без ТЗ над внутренним проектом. Тут каждый участник получает уникальную возможность проявить себя с лучшей стороны. Какой простор для личной критики: “Я раньше и не знал, что работаю с такими конченными рукожопами!”

А сколько можно делать правок! Когда логотип в шапке 18-й раз меняет свой размер на 2 пикселя, потому что “он всё ещё смотрится как-то непрофессионально”, вы начинаете чувствовать, что что-то пошло не так. Но оставьте сомнения! Вы же это не для клиента какого-нибудь, а для себя делаете! Так что не бойтесь еще раз 50 поменять концепцию — это точно поможет бизнесу! Вот почему часто внутренние проекты вполне успешных IT-компаний затягиваются на века.

Версия 4: начинающий разработчик берусь за любой ад


Легче всего охмурить юных нежных разработчиков, которые пламенно жаждут портфолио с крупными громкими проектами, открывающее любые двери. Но, как известно, без ТЗ получается ХЗ. А потому все это стыдно вообще кому-то показать, если конечно удастся дотянуть этот ужас до конца. “Вот, мы тут делали… И почти доделали! Оно не работает, но, в целом, видно суть”.

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

Частенько портфолио собираются по принципу: “Мужик, ты на Drupal-е чего-нибудь собирал в этом году? Дай списать!” Клиенты — такие затейники, и часто их не устраивает “просто портфолио”. С меня как-то потребовали портфолио CRM для ТРЦ, чтобы подтвердить мою компетенцию в данной области.

Версия 5: важный клиент


Здесь так не принято. Мы никогда нигде и ни с кем так не работаем. Помните эксперимент, когда всех обезьян в клетке поливали ледяной водой, если одна из них покушалась на бананы на верхушке лестницы? Нарушительницу больно били, и за бананами никто не лез. Потом в клетку подсаживали новенькую, она лезла за бананами – тут же получала люлей, а потом уже сама мутузила очередную новенькую. Ученые по одной заменяли всех обезьян в клетке, и постепенно остались только приматы, которые ледяного душа в глаза не видели, но за бананы новеньких продолжали бить.

Я это к чему? В крупных компаниях работают как раз такие обезьяны: «У нас в компании принято платить за финальный результат с отсрочкой платежа 60 дней!».

Что ж, тогда остается только опросить разрабов, получить среднепотолочную оценку «этого», умножить ее на 3… нет, лучше на 5, и смело вписывать в КП. Купят – хорошо, не купят – и слава богу, потому что драть будут, как за Х10, всею вертикалью власти от младшего стажера до генерального.

Конечно же, может найтись «свой хороший мальчик», который все сделает в два раза быстрее и дешевле. Надо встретить такого мальчика с позитивом, пообещать помочь советом, если что! А ближе к концу (предполагаемому) проекта позвонить и поинтересоваться: «Как дела?».

На самом деле, крупные компании не боятся крупных сумм, особенно если ты их можешь обосновать. Если ты выехал за их бюджет, тебя попробуют уломать на скидон. И тут можно выцепить из всей тусовки, которая, как правило, заваливается на встречу, более-менее вменяемого человека и попытаться объяснить ему, что есть такой хитрый способ с ТЗ, предварительным описанием контента, экранов и сценариев, который волшебным образом может снизить сумму – надо только эту работу оформить и провести как-нибудь так… Как-нибудь так отдельно и авансом… За счет другого бюджета. Ну, они там у себя лучше знают.

Версия 6: неквалифицированные заказчики


Допустим, приходит к вам что-то незамутненное с развесистыми ушами, считающее что программное обеспечение находят в капусте, прямо как детей.

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

Версия 7: программист на зарплате


Хорошая зарплата и кодить — это вторая по популярности мечта программиста после оплаты по часам. 250К, соцпакет и прямо в рай! И жизнь удалась! What a beautiful life! На самом деле, нет. Даже такие условия можно превратить в ад.

Итак, приходит к разработчикам звезда пиара aka PR-менеджер и сообщает, что ей срочно-срочно надо поднять маааленький сайтик с регистрацией, мини-играми, начислением баллов за активности и магазином призов. Разработчик на зарплате любезно сообщает ей, что она должна скачать с GitHub стандартную форму ТЗ (содержащую, например, такие поля как “требуемый уровень безопасности данных пользователей” и “предполагаемый уровень пиковой нагрузки на сервер”), заполнить её и закоммитить обратно. Подробную инструкцию о том, что и как, она без труда найдет на корпоративной вике. Звезда пиара уходит, как обоссаный кот, но, в отличие от программиста-аутиста, она на то и звезда пиара, что умеет общаться с нужными людьми, поэтому начальнику отдела разработки прилетает по макушке, он достает наручники и пристегивает программиста к батарее на сутки-двое, пока тот не запустит маааленький и очень срочный промо-сайтик. А звезда пиара уже довольная бежит к нему с дизайном, который сделал гениальный маэстро из отдела медийной рекламы и который можно натянуть разве что на… Ну, вы поняли.

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

Версия 8: лень, некому делать ТЗ


“Я разработчик, и я не хочу писать ТЗ, я хочу алгоритм и копи-пейст!” Но почему бы не попросить клиента решить эту проблему? Аналитик вполне может быть на стороне клиента и выдать что-то вполне вменяемое.

Если аналитика нет ни у клиента ни у вас, ну так наймите же его и выставьте клиенту счет!

Версия 9: заказчик не знает как должно быть


Что может быть круче, чем неквалифицированный заказчик? Однажды я писал ТЗ для школьника. Ну т.е. заказчиком был школьник, наверное, очень богатый школьник. Это был самый сложный для меня проект, т.к. очень многое пришлось придумывать самому — просто у молодого человека не было какого-то мнения по многим вопросам.

Бывает, что заказчик так и говорит: “Я не знаю, чего хочу — предложите варианты!” И очень хочется начать делать эти варианты, но надо взять себя в руки и составить ТЗ на варианты (да-да, варианты тоже должны делаться по ТЗ).

Версия 10: ради будущих крутых проектов


Когда я дописывал эту статью со своим прекрасным редактором, к нам пришел приятель и рассказал, что берется без ТЗ ради будущих проектов:

— Сейчас возьмусь за копейки и без ТЗ, зато, потом они купят у меня мегапроект по нормальной цене!
— Но почему?!
— Я в это верю! И мне реально интересен этот проект!
— Но почему они купят?
— Аааа, не знаю! Ну, о-кей, вы меня застыдили! Я больше не буду так делать!

Версия 11: “Я хочу, чтобы у вас глаза горели!”


Бывают такие заказчики-искусители, шоу-мены, ораторы от бога, которые умудряются разжечь нехилый интерес к проекту даже у самого прожженного разраба с тленом в глазах. Я часто слышу именно такую фразу: “Я хочу, чтобы у вас глаза горели!” — и она сразу заставляет меня насторожиться. Часто подобные заказчики сопровождают свои речи щедрыми обещаниями доли в проекте или роли эксклюзивного оператора сверх-успешного продукта или сервиса. В общем, разработчик начинает верить, что делает проект для себя, а тогда зачем такие формальности, как ТЗ?

Я безмерно уважаю людей с горящими глазами, но, пожалуйста, оставьте немного вашего сухого горючего на ТЗ!

Вывод


За всю мою деятельность отказ от ТЗ ни разу не помог упростить проект или заработок. Проблема в том, что в IT-проектах ТЗ пока не стало такой же обязательной частью подготовки. Как, скажем, в строительстве, где без проекта не рекомендуется строить даже деревенский сортир.

Разработчики, ну пожалуйста, сделайте ТЗ отраслевым стандартом и научите клиентов, что иначе не бывает.

PS: Не забываем писать в комменты почему и как вы взялись без ТЗ, кто вас к этому склонил, какие хитрости и уловки использовал.

UPD:


Тут пользователь сформулировал важные фундаментальные вопросы на тему «Что есть ТЗ? Что делает аналитик?», спасибо ему! habrahabr.ru/post/315624/#comment_9952198
Спасибо всем комментаторам, благодаря им обсуждение получилось гораздо интереснее, чем сама статья.

habr.com

От идеи до реализации. Часть третья — создаем ТЗ (техническое задание) / Habr

Данилевский Кирилл

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

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

Но для того, чтобы заинтересовать инвестора, вам необходимо предоставить ему достаточно подробные документы. Так как разговор с объяснением, грубо говоря, на пальцах, не дает инвестору возможность увидеть картину целиком. А следовательно и о деньгах тоже не может быть никакой речи.

И наша главная задача — это подготовить такие документы, которые помогут вам получить финансирование и смогут вам самому прояснить картину с будущим вашего проекта.

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

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

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

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

Идея интересная, уже более-менее сформированная. Начинаются поиски инвестора, который готов вложить в эту идею финансы. Но первый вопрос — сколько нужно вложить денег в этот проект? И ответа на этот вопрос нет. И второй момент — это если инвестор не разбирается в физике, то он вообще не поймет того, что ему будут пытаться объяснить. А вкладывать деньги в то, чего инвестор даже примерно понять не может, он уж точно не будет.

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

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

Теперь переключимся на работу системного аналитика. Есть задача — разобраться в принципе работы бизнеса, создать документацию, которая сможет оценить время, необходимое на разработку программного обеспечения. Оценка времени, как правило, может быть либо грубой, либо более-менее детальной. В первом случае не будет создано подробное техническое задание, а будет только создана модель архитектуры. Во втором случае будет разработано детальное ТЗ, которое уже будет готово для старта процесса разработки.

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

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

СОЗДАЕМ ТЗ ДЛЯ ПРОЕКТА

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

1. Очень подробно описывается идея проекта. Аргументируется эта идея. Почему она должна сработать. Какие конкуренты уже присутствуют на рынке. Какая у них доля рынка. Насыщен ли данный рынок или испытывает голодание на подобное решение.

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

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

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

5. Если предполагается, что будет много разных проектов на базе одной платформы, то нужно продумать, как им лучше работать. Не стоит пихать весь функционал в один гигантский сайт. Лучше разнести все по разным серверам. Но тогда придется делать промежуточный сервер, где будет происходить авторизация и т.д.

6. Нужно сразу предусмотреть то, что сейчас вам может и не нужно. Так как когда вам это понадобится, вы потратите финансов в десятки раз больше! Я имею ввиду не сразу создавать функционал, а грубо говоря, построить фундамент для возможного функционала. Как правило, таким фундаментом является свой АПИ, благодаря которому, можно делать разные вещи. Например, подключить лабораторное оборудование, которое будет записывать результаты экспериментов сразу в базу проекта. Или, к примеру, можно будет продавать для разных партнеров доступ к вашим данным.

7. После того, как были изучены тонны документов по физике, понятна суть проекта и на основании этого создана модель базы данных, то самое время подумать над тем, как эти данные будут записываться в базу, и как они будут получаться из базы. А значит, требуется продумывать интерфейсы, через которые будут заноситься данные. Речь сейчас идет именно о статистических данных, на основании которых будет коррелироваться результат расчетов.

8. Нужно продумать независимую модульную систему для формул, которые будут производить расчет. Формулы должны быть не связаны друг с другом и полностью независимы. А уже в самом проекте, когда и где это необходимо, то обращаться к формуле, отдавая ей данные и получая от нее результат. Это вам позволит, в случае каких-либо изменений, сделать изменения только в маленьком и отдельном модуле. При этом ничто другое не пострадает и не повлияет на работу самого проекта.

9. Для подобных сложных проектов просто необходима система самодиагностики. Она должна быть разбита на две части. Первая — это диагностика базы данных, на корректность данных. Ведь речь идет о сложных математических расчетах. А значит, даже маленькая ошибка (например, некий коэффициент в базе равен не 0.5, а 0.6) может привести к фатальным последствиям. Для этого нужно иметь некие эталонные данные, которые будут сверятся с реальными в базе. И если реальные данные вышли за предел допустимого порога, то администратор должен это знать и сам принять решение, что с этим делать. Тоже касается и формул вместе с входными параметрами. Параметры должны быть только в рамках допустимой погрешности.

10. Пользовательский интерфейс. Этот вопрос тоже очень важен. Система должна быть интуитивно понятна, легка в использовании и очевидна.

11. Система защиты данных и общая взломоустойчивость. Об этом моменте тоже не стоит забывать. Если какой-то хакер сможет обрушить ваш сервер или украсть ваши данные, то не о каком бизнесе тогда вести речь будет нельзя.

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

13. Система подробного анализа пользователей. Производимых ими расчетов и действий в системе. Это поможет находить узкие места в проекте и улучшать качество вашего приложения.

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

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

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

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

Естественно, то о чем я сказал выше, касается сугубо профессионального подхода. Если делать это на тяп-ляп, типа «и так сойдет», то получим примерную картину того, почему большая половина интернета представляет из себя помойку, а не технологический шедевр.

Всем спасибо и до новой встречи.

habr.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *