Как правильно написать техническое задание для разработки мобильного приложения?
Некоторые идеи (не все) при написании ТЗ для мобильного (НЕ по ГОСТу)Этапы разработки (при условии что уже есть концепция):
Обследование
Интервьюирование
Прототипирование
Описание требований
Обследование:
Оцените масштабы приложения — определите структуру
Подготовьте план вопросов по проекту — оцените возможные «белые пятна»
Рекомендуется организовывать план обследования для крупных проектов
Набросайте сценарии использования, соотнести с конкретной ЦА
Определите, как будет работать приложение (автономно, посредством сети, комбинировано)
Определите технические требования к приложению: платформа (android, IOS или др.), разметка экрана (под смартфон, под планшет и др..), тип верстки (резиновая верстка, адаптированный дизайн), ориентация экрана (горизонтальная, вертикальная) и т.д
Интервьюирование (пропускаем)
Прототипирование:
Соотносите размеры элементов интерфейса прототипа с реальными размерами экранов
Учитывайте удобство зон касания на мобильном устройстве — выводите самые часто используемые элементы в зону удобства касания на экране
Востребованные функции и контент на первый план, второстепенный скрыть в меню
Продумывать как правильно расположить точки монетизации приложения — они должны быть на виду, но не мозолить глаза
В навигации реализуйте возврат к предыдущему экрану (Назад) там, где это может помочь исправить некорректный или ошибочный пользовательский ввод
Описание требований:
При разработке ТЗ, определитесь из каких разделов будет состоять его структура, есть ли возможность оптимизировать эту структуру
Избегать повторений в описании, в том числе выносить общие элементы в отдельное описание
Ориентируйтесь на краткость и информативность написания текста
Маркируйте описание общих требований для сложной структуры данных
Отдельно прописывайте бизнес-процессы
При проектировании приложения для мобильного телефона учтите возможность поступления вызова в ходе передачи данных или выполнения программы, а также обрывы сети
Для каждого экрана в общем описании прописывать вход и выход процессов совершаемых над ним
При описании элементов интерфейса можно придерживаться структуры (Подходите к вопросу с головой, не описывайте структуру там где она не нужна):
состав — описание состава элемента, если содержит в себе несколько элементов (например поле с подсказкой)
описание — что делает элемент, дополнительные свойства, возможности
источник данных — откуда подгружаются данные для элемента: локально или из API, куда уходят: в API в КЭШ
режим обновления — частота обновления данных, в некоторых случаях выносить в общее описание активити (исходить из структуры экрана)
состояния — описание возможных стейтов, статусов, режимов, видимости
режим доступа
Это только малая часть того что следует учитывать… лучше когда ТЗ пишет спец
qna.habr.com
дорога в никуда / RegionSoft Developer Studio corporate blog / Habr
Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.Первая часть о том, как составлять техническое задание — по ссылке.
Мы — разработчики CRM. Наша RegionSoft CRM — довольно мощное профессиональное решение для бизнеса. Система десктопная и нам очень часто достаются клиенты, которым нужен полноценный проект внедрения с заточкой под индивидуальные особенности клиентов. У кого-то это особый цикл продаж, кому-то нужно отслеживать транспорт, третьим необходимы особые отчёты, настройка системы KPI или бизнес-процессов. Плюс, ещё встречаются особенности внедрения, например, распределённые офисы, филиалы, настройка телефонии, торгового оборудования и т.д.
В частности для CRM, а в целом для любого корпоративного программного обеспечения подходит схема: лицензии + доработки + внедрение. Клиент может купить лицензии, установить ПО, самостоятельно взять документацию, разобраться и начать работать. Может купить лицензии, заказать доработку, а остальное сделает сисадмин. А может купить лицензии и заказать внедрение. Ну и связка из всех трёх элементов также возможна. Так вот, этапы доработки и внедрения всегда требуют составления технического задания, в котором будут поэтапно указаны все работы, сроки, цены и прочие условия.
Мы бы не вздыхали и не поднимали проблему работы с ТЗ ещё раз, а пилили бы и пилили код всей командой разработки, если бы не камень преткновения, с которым мы встречаемся очень часто — клиенты не хотят составлять техническое задание на доработку. Не хотят ТЗ, то есть фактически находят верный способ никогда не подписать акт. Вот самые распространённые причины.
- И так всё понятно — зачем тратить время?
- Здесь всё просто! Да я на пальцах объясню.
- Я не умею его составлять.
- Почему я должен платить за то, что войдёт в следующий релиз?
- Вы составляете ТЗ за деньги?!
Давайте рассмотрим эти вопросы в деталях, потому что одним абзацем списка явно не обойтись.
ТОП-6 фраз клиентов — верный способ разозлить разработчика
И так всё понятно — зачем тратить время?
Комментарий разработчика: Чтобы определить четкие задачи и цели, формализовав их на бумаге. Ведь то, что оговаривается устно, нельзя использовать в качестве прямого указания к действию. Также, устные договоренности впоследствии легко трактовать кому как удобно. А если ТЗ объемное и требует длительного срока реализации, кто потом будет вспоминать о том, какие именно формулировки использовали стороны, когда оговаривали требования к доработке?
У нас есть базовое решение — CRM, к ней есть требования по доработке. Бывает, мы берёмся за разработку целых модулей или дополнительного к CRM программного решения (как у нас вышло, например, с GeoMonitor и RegionSoft Retail). У клиента есть бизнес, который он хочет автоматизировать. У него есть набор проблем, которые эта автоматизация должна решить: повысить продажи, упорядочить процессы, сократить время на рутину, сделать прозрачными сделки и склад и т.д. Нам понятно, как работает наш софт, клиенту — как функционирует его бизнес. И когда мы встречаемся, то должны понять друг друга.
Как понять друг друга, работая над ТЗ?
- Говорить на общепонятном русском (другом) языке. Вряд ли каждый клиент поймёт фразы «бэкапить базу на резервный сервер» или «накатим апдейт на продакшене». Нужно выслушать обе стороны: рассказ вендора о возможностях софта, рассказ клиента о нуждах бизнеса, задать вопросы и приступить к составлению ТЗ именно по тем фичам, которые реально нуждаются в доработке.
- Делать техническое задание поэтапным: разделить предстоящие работы на блоки с указанием суммы и сроков по каждой из групп работ.
- Лучше всего, если от заказчика в процессе будет принимать участие технарь или человек, знающий процесс до самой мелкой вехи. При всём уважении, стандартный офисный маркетолог CRM не внедрит.
В общем, правило такое: чтобы всем всё было понятно, все фичи, подлежащие доработке, должны быть проговорены устно и формализованы на бумаге.
Здесь всё просто! Да я на пальцах объясню
Комментарий разработчика: Бывает так, что небольшое изменение в одном механизме каскадом тянет целый набор связанных изменений в других местах, что необходимо проанализировать и учесть при подготовке к работам. Бывает и так, что для реализации вроде бы простой задачи требуется внести существенные изменения в движок механизма, изменив его архитектуру. Составление ТЗ помогает продумать эти моменты и выработать правильные решения, в результате чего работа будет выполнена качественнее, с меньшим количеством ошибок и отладки, а в процессе разработки будет меньше подводных камней и «сюрпризов».
Заказчику кажется, что изменить цикл продаж, создать один отчёт или прикрутить диаграмму Ганта — просто. Более того, наверняка он погуглил или ему рассказали, что это делается в несколько десятков строк кода. Да, сам код перечисленных сущностей опытным программистам по плечу, но заказчик не догадывается о том, что всё это нужно встроить в архитектуру основной программы и ради «ну там небольшой доработочки» придётся основательно менять логику какого-либо модуля или системы.
Поэтому важно внимательно изучить базовую функциональность программы, сопоставить её с потребностями бизнеса и понять, чего действительно не хватает. Сделать это просто: ставите основным пользователям демо-версию и работаете в системе несколько дней, фиксируя в отдельном документе, чего не хватает вашей команде. Затем в списке нужно расставить приоритеты, исключить пересечения подразделений, ещё раз сформировать документ и обратиться с этим списком к вендору, который совместно с заказчиком приступит к составлению ТЗ.
Я не умею его составлять
Комментарий разработчика: Но Вы же можете на простом языке озвучить требования к функционалу, которые должны быть созданы. Это можно сделать в тезисном виде, а детали оговорить устно. Но в итоге, ТЗ составляет разработчик на основе Ваших требований и с учетом всех деталей. Ведь Вы не вправе рассчитывать на то, что Вам будут сделаны работы, не оговоренные в ТЗ! Вы за них даже не платили… Верно?
Получается, главное — донести требования. ТЗ — это рабочий документ для того, чтобы понять назначение, цели и видение продукта. По нему будет подписываться акт, по нему же будут вести разработку программисты из команды вендора. Для них это — инструкция, согласно которой они продвигаются в разработке. ТЗ — совсем не обязательно 100 страниц (хотя бывает и 400, ну это в крупных интеграционных проектах), это может быть и пара пунктов, но они обязательно должны быть. Клиент, в свою очередь, сможет принять работы, сверяясь с техническим заданием — и в случае коллизий показать разработчику на то, что сделано не так. Ну или наоборот.
Почему я должен платить за то, что войдёт в следующий релиз?
Комментарий разработчика: Никто заранее не знает, войдет ли доработка, заказанная Вами, в типовое решение в будущих релизах. Это определяется гораздо позже на совете разработчиков при подготовке глобальных обновлений. Однако действительно, любая доработка при её полезности для широкого круга потребителей, может быть включена в типовое решение. Это право разработчика и оно не обсуждается.
У нас есть такая практика — лучшие решения и доработки мы вводим в релиз. Кто видел RegionSoft CRM поближе, могли заметить, насколько она функциональна и глубока по набору возможностей. Это достигается именно за счёт непрерывного внедрения новых функций, в том числе из клиентских запросов.
Но вопрос совершенно некорректен — во-первых, не факт, что доработка войдёт в релиз. Во-вторых, вам она нужна сейчас, вы её инвестор и она будет реализована для вас в кратчайшие сроки, протестирована на ваших данных и внедрена вам. Релиз же именно с вашей фичей может случиться через год-полтора, потому что беклог большой — обычно на пару мажорных релизов вперёд. Причём все задачи из беклога в обязательном порядке обсуждаются внутри команды на предмет актуальности и необходимости внесения функциональности в релиз. Наконец, даже если крутая доработка попадает в новый релиз, она глубоко рефакторится, подвергается универсализации и, вполне возможно, будет значительно отличаться от Вашей реализации.
Да программисты ничего не понимают в продажах (бизнесе, складе, бухгалтерии и т.д.)!
Комментарий разработчика: Понимают или нет программисты в продажах — никак не коррелирует с необходимостью составления ТЗ. Оно составляется для того, чтобы отдел разработки мог выполнить конкретные реализации задач и сдать заказчику готовые механизмы.
Здесь даже стоит развернуть ответ по пунктам:
- Программист может участвовать в обсуждении, но составляет ваше ТЗ и будущую архитектуру доработки/логику внедрения инженер/главный разработчик (он может называться и тимлидом, и продакт-менеджером, и продакт-овнером), который прекрасно знает бизнес со стороны клиента — иначе бы просто никто не запроектировал столько функций, не понимая, как они смогут работать внутри бизнес-процессов.
- Заказчик сам — консультант вендора, и когда он понимает, что хочет, разработчику гораздо легче.
- Вендор разбирается в бизнесе хотя бы в силу того, что он сам по себе бизнес и работает со своими же продуктами как клиент. Например, у нас в Регионсофт у всех сотрудников стоит RegionSoft CRM — мы её используем по всем сценариям: как инструмент продаж, обзвона, рассылок, багтрекер, журнал корреспонденции, интегрируем с 1С, ставим задачи, планируем, оцениваем KPI и проч. Соответственно, есть чёткое представление о том, как работает средний клиент. Кстати, отличный способ тестирования программы.
Как правило, компания-разработчик всегда эксперт в той отрасли, для которой она разрабатывает. Без этого можно писать отдельные скрипты и модули, но ни в коем случае не комплексные системы.
Вы составляете ТЗ за деньги?!
Комментарий разработчика: Для того, чтобы составить ТЗ, необходимо выполнить определенный объем работ. Это могут сделать только специалисты с достаточно большой квалификацией, которые знают систему изнутри и понимают желания заказчика. Это непростая работа. Порой от продуманного и качественно составленного ТЗ зависит весь успех реализации проекта.
Конечно, за простенькое ТЗ из двух-трёх пунктов деньги не берутся. А вот за остальное нужно платить как за часть проекта. И тут есть ряд экономических, функциональных и даже психологических причин, о которых стоит рассказать подробнее.
- Сотрудники, которые составляют ТЗ на стороне разработчика (как правило, это 2 человека и более), тратят на него своё рабочее время, сдвигая другие задачи. Соответственно — это работа.
- После составления ТЗ клиент может уйти к конкуренту с готовым «подарком» — почему мы должны им оплачивать этот этап работы?
- ТЗ — это часть интеграционного проекта, и определённые функциональные работы проводятся ещё на этапе его составления.
- То, что дано бесплатно, не ценится — клиент относится к документу как к необязательной бюрократической формальности. В то время, как это должен быть основной рабочий документ.
Кстати, «инвестирование» в ТЗ чаще всего приводит к гораздо большей, чем его стоимость, экономии: вы платите только за точные, обоснованные доработки. Но это не значит, что составив ТЗ, нельзя больше внести ни одного замечания. Можно. Внеся предварительно дополнительные работы в существующее техническое задание.
Я подразумевал другое!
Комментарий разработчика: Мысли человека неисповедимы. Сегодня я хочу зеленый чай, а завтра меня потянет на кофе. Если нет ТЗ, то невозможно спрогнозировать, что заказчик подразумевал, когда говорил, например, что «по нажатию на зелененькую кнопочку должна происходить интеграция с 1С». Что это означает? Трактовок может быть масса. Может нужно загрузить оплаты из 1С в CRM? А может выгрузить счета? Или нужно вывести отчет о складских остатках? В ТЗ должна быть однозначность.
Если вендор идёт на уступки и соглашается работать без технического задания, то он, скорее всего, услышит именно это возражение, когда настанет момент подписывать акт выполненных работ. И возразить, извините за тавтологию, ему будет нечего. Равно как и доказать, что клиент должен платить за переделывание всего, что ему представлено. Но отсутствие ТЗ делает беззащитным не только разработчика, но и самого клиента.
Обычно после нескольких итераций того, что подразумевал клиент без ТЗ, получается примерно так
Формулируя задачи и меняя их на лету без документа в основании, заказчик фактически подписывается на бесконечный проект. Из-за высокой неопределённости команда вендора не будет видеть конца и края исполнению всех требований и сотни оговорок к ним, а значит, постепенно начнёт откладывать доработку и внедрение в пользу более чётко обозначенных задач. Это не обиды и не ссора — это оптимизация труда и бизнес. Сам же клиент должен быть заинтересован в быстрой реализации проекта — поскольку автоматизация бизнеса это конкурентное преимущество и это рабочий инструмент. Чем быстрее вы его получите — тем быстрее вы выйдете на новый уровень организации труда, производительности и, в конечном итоге, доходности.
Бизнес-аналитики и ТЗ
Это настолько хрестоматийная и невыносимо ужасная история, что ей обязательно стоит посвятить отдельный блок поста. Моду на бизнес-аналитиков ввёл SAP. И они у SAP по всему миру очень мощные ребята с сильным техническим, финансовым и менеджерским бэкграундом. Саповцы, особенно за границей, отлично знают цену времени, срокам, ТЗ. В России, мне иногда кажется, они переняли только напор в общении, отглаженные костюмы и слова типа митап, колл, фидбэк, фоллоу-ап (пообщайтесь при случае — бизнес-аналитики прикольные ребята!). У нас я встречал бизнес-аналитиков с гуманитарным образованием, с незаконченным высшим и даже без знания основ работы с ПК. Это такие продажники на стероидах. И вот они выступают адвокатами сделки и берутся составлять ТЗ. Тут возможны варианты.
Всё же готово — берите и делайте! На моей практике есть несколько десятков случаев, когда люди приходили с готовыми большими ТЗ, подготовленными сторонними консалтерами. Однако ни одно из них так и не дошло до реализации. Все грязло в обсуждении этого большого ТЗ. На этом и заканчивалось. В данном случае ТЗ вам пишет совершенно посторонний человек, который знает, как ведёт себя CRM в бизнесе в общем случае (фактически стерильные лабораторные условия), но совершенно не знает, как поведёт себя выбранная вами программа в вашем собственном бизнесе. Или же он составит вам ТЗ таким образом, чтобы под него подошла не та программа, которая вам нужна, а одна из тех, которую ему нужно продать за процент от сделки.
Вот тут же всё про CRM! Люди приходят опять же от бизнес-аналитиков с готовым ТЗ, которое совершенно не согласовано с нашим ПО и для его реализации нужны огромные деньги, поскольку требуется перепиливать сложные механизмы системы, вместо того, чтобы адаптироваться к системе и дополнить ее недостающими возможностями.
Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось. Старое техническое задание — это мёртвое техническое задание. Бизнес-процессы изменились, кураторы проекта уже другие, модернизировалась ИТ-инфраструктура, вырос уровень CRM-систем. 7 лет для бизнеса и ИТ-сферы — это значительное время, равно как год или два, поэтому старое ТЗ попросту не актуально.
Мы взяли ТЗ у наших партнёров, они недавно внедрили. Очень странный подход. Не бывает двух одинаковых компаний и одинаковых процессов внутри них. К тому же, если было внедрение другой CRM-системы (иного софта), то не может быть и речи о том, чтобы принять это ТЗ в работу — технологии от вендора к вендору сильно отличаются (даже, если системы написаны на одном языке программирования и визуально друг друга напоминают).
Самый адекватный вариант — клиент приходит с бизнес-аналитиком. Тут хотя бы можно посмотреть ему в глаза оценить его уровень и приступить к обсуждению, просто с участием ещё одного лишнего человека. Но по опыту, толку от бизнес-аналитика очень мало — он либо будет вас сманивать на ту (те) программу, которая ему приплачивает, либо окажется третьим лишним и платным в отношениях между вами и вендором. Команда разработчика достаточно профессиональна, чтобы понять ваши требования.
Итак, подведём итог рассуждениям.
- Техническое задание должно составляться на любую доработку и любое внедрение.
- Над техническим заданием всегда работают две стороны.
- Составлять ТЗ выгодно и заказчику, и подрядчику.
- Техническое задание не должно быть формальностью или элементом бюрократии.
- ТЗ — основной инструмент команды программистов.
- Старые, шаблонные, чужие ТЗ ничем не помогут вашему проекту.
- Составление ТЗ значительно ускоряет сроки сдачи всего проекта.
Техническое задание — первая и важная часть интеграционного или внедренческого проекта. Именно от него зависит, насколько быстро и качественно команда справится с работой, а заказчик получит желаемое ПО, работающее, как часы. За границей появилось много адептов работы без ТЗ, они ратуют за свободу творчества и доверительные отношения, войны разворачиваются вокруг слова «требования» (Product Requirements Document). На самом деле, это холивар ради холивара — работать без технического задания в корпоративной сфере как заказчику, так и вендору невозможно. Нужно уметь договариваться. И поля ТЗ — лучшее место для этого.
Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.
И мы просим тех, кто не прошёл, пройти опрос о CRM, о результатах которого обязательно расскажем перед самым Новым годом — в том числе о механике опроса и своих косяках. Просим вас ответить на вопросы в простенькой форме — их всего 10 плюс 3 для тех, кому интересно узнать о нас больше. Просьба дойти опрос до конца, ненужные вам пункты просто пропустить.
Пройти опрос тут
habr.com
С чего начать писать тех.задание? — Хабр Q&A
1. Писать должен тот кто разбирается и в ИТ и в бизнес процессах — это идеальный вариант. Но подходит для мелких компаний с технически продвинутым персоналом.2. На практике — это тандем ИТ-шника и того, кто разбирается в конкретном бизнес-процессе (иногда таковых несколько человек — по каждому процессу — свой). Фактически ИТ-шник допрашивает с пристрастием разных людей, имеющих отношение к бизнес-процессу. И записывает с их слов, интерпретировав в технический язык.
Тут крайне важно, чтобы интервьюироваемые не перекладывали на ИТ-шника. Типа «ты же специалист, должен все знать». Я обычно отвечаю: «Вы хотите чтобы я ваши проблемы решил или свои».
Дело ИТ-шника понять и перевести на технический язык. Но ни в коем случае не самому описывать бизнес-процессы. Бизнес процесс должен описать тот, кто этим занимается.
Причем, важно!!!
Иногда начальники не очень хорошо представляют мелочи, которые будут важны для тех. задания.
Поэтому нужно общаться и с руководством и с простым сотрудником, которого затрагивает то, что описывается в тех. задании.
На самом деле ТЗ не всегда нужно.
Если заказчик согласен вечно платить почасовку — можно без ТЗ.
Это позволяет сэкономить кучу времени и быстро подстраиваться под изменения бизнеса.
Но это возможно только если заказчик может и согласен платить без ограничений.
Такое возможно, если сумма денег которые тратят на исполнителя — для заказчика копейки.
Или заказчик безоговорочно доверяет исполнителю (и исполнитель по карману заказчику)
Есть еще вариант —
делается примитивный прототип MVP
https://en.wikipedia.org/wiki/Minimum_viable_product
По нему оценивают и тех. задание составляют/уточняют.
Но делать такие вещи обычные заказчики отказываются,
только те, кто работает с большими и дорогими вещами — согласны.
Это серьезно уменьшает их риски.
Не совершайте ошибку — не пишите замороченными словами.
Нужно писать обычным человеческим языком.
ТЗ — это намного более простая вещь, чем обычно представляют.
Это просто описание человеческим языком всех нюансов.
qna.habr.com