Алгоритм работы с техническим заданием заказчика

Эта статья основана на личном опыте разработчиков компании Neti и расскажет Вам о том, как анализировать и оценивать технические задания, а также как предоставлять результаты разработки заказчику.

4 способа оценить задачу, чтобы не прогадать

1. Разброс оценок «от и до». Применяется, если невозможно дать точную оценку, например, задачи типа обновления сильно измененной конфигурации 1С (когда изменения вносил не тот же программист, который их переносит), некоторые проектные работы, которые завязаны на длительное обсуждение с пользователями в процессе разработки или привлечения третьей стороны.

Разброс помогает определить общий бюджет 1С-задачи. По итогам дается фактическая оценка. Если становится ясно, что фактические затраты, возможно, выйдут за изначальный промежуток, то это сразу сообщается Клиенту.

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

Также применяется, если существует вероятность некоторых изменений неосновных моментов. Как? Задача оценивается как общая разработка, с запасом (определяется отдельно) на обсуждение и переделку конкретных моментов — по итогам реализации.

3. Оценка с небольшими техническими вопросами. Реализуется, когда, по итогам уточнений, у вас есть четкое и полное описание задачи в терминах пользовательской части системы.

Сначала уточняется все, кроме несущественных для пользователя моментов реализации (технических и быстро изменяемых). Потом оценивается общая реализация с рисками на сложность разработки, с учетом, например, разных технических способов решения одной и той же проблемы. Указанные риски могут быть нулевые, если вы все это уже реализовывали и у вас есть рабочий пример.

4. Оценка по жестко и полностью прописанному заданию (и бизнес-блок, и часть технической реализации). Используется, когда на стороне заказчика есть свой отдел разработки 1С, со своими стандартами. Как? Уточняется целиком бизнес-логика задания (для чего это нужно пользователю, что в итоге получим и т.д.), анализируется и уточняется техническая архитектура 1С-задачи, предоставленная заказчиком, или предлагается и согласуется наш вариант реализации. Такая работа оценивается максимально точно.

«Метод двойного подхода» при анализе больших и непонятных ТЗ

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

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

Второй подход (чтение с добавлением вопросов). Уточнения для себя конкретных моментов. Выбор конкретных методов реализации. Составление вопросов по неясным моментам. Доработка идеи структуры общего механизма. Продумывание сложных моментов соединения таблиц, структур регистров.

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

Плюсы двойного подхода: 

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

Когда и как подключать к работе эксперта

1. Если вам не достает знаний для анализа или оценки техзадания  в какой-то области, то лучше привлечь эксперта. Узнайте, кто в этом разбирается и договоритесь, что вам помогут. Или обращайтесь к руководителю с вопросом поиска эксперта, на правах внешнего консультанта.

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

Как узнать все, что нужно, и не показаться дураком.


Основные принципы уточнения заданий

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

1. Способы задавать вопросы

1.1. Размещайте вопросы в файле ТЗ и пересылайте его уже почтой – это наиболее безопасный и правильный подход (если по почте отвечают быстро или сроки не горят), так как все сразу видно в одном файле. Способ делится на вопросы:

  • В примечаниях (сбоку).
  • Выделенные другим цветом и шрифтом прямо в тексте.
  • Методом исправления (Word). Данный файл по итогам прикрепляется к задаче учетной системы (например, JIRA).

1.2 Когда нет отдельного файла технического задания, фиксируйте вопросы в теле письма. В таком случае размещайте в задаче учетной системы (например, JIRA) все обсуждения. Хотя бы методом «Копировать» — «Вставить» из письма.

1.3. Избегайте вопросов в скайпе. Переписка в скайпе редко может считаться доказательством договоренностей с консультантом (там можно и отредактировать и удалить текст, сообщения не хранятся на сервере). Сообщение в скайпе забываются или, в связи с отсутствием внешнего сервера хранения сообщений, теряются. Да и просто вы можете попасть на неудобное для консультанта время, и он, бегло прочитав вопрос, неправильно его поймет.

Поэтому все итоговые обсуждения, или выясненные, например, за день вопросы, фиксируйте письмом. Кратко описывайте принятые решения с вступительным текстом, например «Дублирую обсуждение по Skype письмом». Так же опять же тот же текст копируется в учетную систему (например, JIRA) в комментарии к задаче.

1.4. Переводите в текст вопросы голосом по скайпу или по телефону. При устном общении в любом случае лучше фиксировать договоренности и ответы письмом аналогично предыдущему пункту. Так же опять же тот же текст копируется в учетную систему (например, JIRA) в комментарии к задаче.

1.5. Собирайте и систематизируйте всю информацию в один файл. По 1.2, 1.3 и 1.4 пунктам лучше копировать получившиеся тексты обсуждений в текст техзадания (для простоты, например, после основного текста). Чтобы всегда можно было одним файлом переслать файл со всей информацией.


2. Принцип задавания вопросов – «90% и сразу»

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

3.    Методы утончения вопросов

3.1. Варианты своего понимания вместе с уточняющими вопросами. Если это уместно, (становится ясно при первом общении с консультантом 1С) при непонятной формулировке в техническом задании, можно предлагать в тексте свои варианты понимания задачи. То есть «Имеется в виду, что или все же . Если первое, то вопрос такой:  .

3.2. Переспрашивайте – для надежности. Если написано все вроде бы понятно, но вы не уверены, то лучше так и спросить: «Я правильно понял, что ..?».

3.3 Отсроченная сила «висящего в ящике письма». Кроме вышеназванных минусов вопросов по скайпу и по телефону, есть и такой, что человек устает говорить и, с легкой руки подсознания, сбрасывает все – то есть забывает, что хотел сказать. Письмо же висит и ждет ответа.

3.4. «Вечером – вопросы, с утра — ответы». Если отправка вопросов по почте затянулась до вечера, то лучше и отправлять письмо прямо вечером, а не затягивать до утра. Тогда с утра на той стороне сразу увидят письмо. Если же вы отсылаете письмо днем, то день к тому времени уже распланирован, и люди могут не найти время.

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

6 правил точной оценки трудоёмкости задачи

Как свести к минимуму вероятность оценки «от балды»?

1.    Оценка по методу PERT. В нашей компании разработчики 1С используют оценку по методу PERT. 
Данная оценка выполняется так:

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

б. Прогнозы решения задач – по шкале оптимизма. Для каждого блока рассчитывается оптимистичная, реальная и пессимистичная оценка. Если вы не сами себе консультант и не знаете все идеально, то оценки, хоть немного, но будут разными! (не считая задачи типа «добавление реквизита, без добавления на форму»).

в. Основной расчет. Далее по математическим  формулам вычисляется оценка по выбранной процентной вероятности выполнения задания.(подробнее о расчетах можно почитать, например, здесь )

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

Реальная – это та трудоемкость, которая по вашему опыту обычно получается: «скорее всего, здесь не все так просто, но я разберусь за такое-то время, плюс обычно возникает еще один вопрос во время реализации, так что плюс время на уточнение».

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

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

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

· На второй странице – в таблицу вбиваются части задачи и их оценки (оптимистичная, реальная и пессимистичная).

2.    Если блок непонятен и нет возможности его разделить:

2.1.    Привлекаете эксперта, если не можете оценить блок.
2.2.    Если эксперта нет, то об этом сообщается руководителю, и задача чаще оценивается с широким разбросом «от» и «до»

3. Примерное структурирование — по пунктам. Блок для оценки — это не целиком объект со всей его функциональностью (если только вы не можете его идеально оценить)! Пункты блоков в оценке — это, например, форма, регламентированное задание, новый регистр, функция, запрос и т.д.

3.1.  Пример. То есть, разработка на 1С отчета с использованием СКД делится на: составление запроса, заполнение параметров из формы отчета, остальная форма, вывод специфики в макете, процесс описания и подключения внешних таблиц, оформление (цвета строк, ширина колонок и т.д.).

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

4. Почему дробление – ваш друг? Чем больше объекты оценивается без дробления, тем хуже оценка. В 90% случаев это значит, что оценка меньше реальной трудоемкости.

5.  Анализ техзадания тоже включается в оценку! По нашему файлу все, что вы потратили на оценку разработки, вы фиксируете и включаете в поле «Анализ» на первой странице.

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

Как сообщать результаты разработки

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

Что вы должны знать о людях как разработчик:

  • Люди по умолчанию не доверяют другим людям.  Поэтому они будут сомневаться, что вы все протестировали, все доделали и вообще сделали то, что нужно.
  • Так же люди разражаются, когда что-то не понимают или не находят, особенно когда это что-то простое. А так как человек вообще не склонен винить себя в чем-то, то он подсознательно будет винить вас, как разработчика такого вот «не интуитивно понятного интерфейса».

6 результатов разработки, о которых стоит написать Заказчику

1. Если вы при разработке сами приняли какое-то решение (не было консультанта или уточнение было не существенно), то об этом надо написать письмом при сдаче задачи. Например: «при открытии обработки поле Организация автоматически заполняется из настроек пользователя, так как это необходимо для дальнейшего автоматического заполнения».

2. Если вы для своих объектов разработали в конфигурации 1С новый интерфейс или добавили пункт в меню в существующий интерфейс, то об этом надо написать обязательно! Конкретно: куда добавили и что там появится при открытии. Пользователь не должен искать, что и где вы создали. Исключением может быть, только если стояла задача – «создать автопоявляющуюся при запуске кнопку «Сделать все» на весь экран».

3. Если вы добавили дополнительно что-то, что вообще не обговаривалось, то опять же об это надо написать. Например «Дополнительно при проведении документа происходит проверка на заполнение реквизитов ».
Заказчику будет приятно, что вы подумали о нем, поэтому пускай дополнительные положительные эмоции появляются стопроцентно,при первом тесте.

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

5. Описание процесса тестирования убережет от негатива. Лучше написать 3-4 предложения, как и что надо сделать для того, чтобы протестировать ваш функционал. Это убережет вас от лишнего, хоть и, возможно, недолгого негатива типа «сходу ничего не понял». А то ведь человек разберется, куда нажимать, а плохое ощущение останется.

6.  Завершайте на мажорной ноте. И главное! Фраза «Если будут вопросы по новому функционалу — пишите. С радостью отвечу» никого еще не убила, но эффект от нее потрясающий – пользователь не нервничает, и поэтому лучше соображает при знакомстве с результатами вашего труда.

PS:  Друзья, пишите отзывы и комментарии

Автор статьи:
Андрей Макаров, компания Neti
Оригинал статьи:
на сайте Аутсорсинг1С.рф 

19 Comments

  1. script

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

    Reply
  2. pumbaE

    Покажите хоть один пример когда «типа обновления сильно измененной конфигурации 1С (когда изменения вносили не мы)» задача упрощается, если вносил изменения ваш специалист?

    Reply
  3. andmakarov

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

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

    Спасибо! (Внесем правки в статью)

    Reply
  4. andmakarov

    (1) script, Вы правы. Метод оценки PERT есть в PMbok. Правда в 4 редакции его раскритиковали как метод оценки проектов, и рекомендовали Монте Карло. Но для оценки конкретных задач, нам кажется, он вполне применим.

    Кроме того, по моему мнению, применение какого-то адекватного метода оценки, всегда лучше его отсутствия.

    Reply
  5. pumbaE

    (3) andmakarov, извините но тема не раскрыта , даже если эти правки вносил всего один закрепленный специалист, т.к. через пол года вряд ли он будет помнить почему в коде вместо «+1» стоит «-1». Обычно никто не ведет список доработок у клиента кто, что и зачем делал поэтому даже одному выделенному человеку невозможно запомнить что менял (если конечно там не 2 -3 правки в год, но тогда и фраза «сильно измененной » не имеет смысла).

    Reply
  6. sapervodichka

    (5) pumbaE, ведение учета изменений зависит от серьезности Заказчика. Обычно в комментарии ставят номер обращения клиента (в ходе сопровождения), либо номер ТЗ или ТП (в ходе разработки, внедрения). Все данные по обращениям и ТЗ храняться у Исполнителя в базе.

    Reply
  7. andmakarov

    (5) pumbaE, да, возможно пример не без оговорок.

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

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

    Так же может быть другая ситуация, правда не связанная с обновлением:

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

    Далее оказывается, что эти изменения, настолько хороши, что надо перенести их на другой проект :). Через месяц, те 5 программистов еще хоть немного, но помнят, то, что писали, и каждый из них быстрее разберется в своем коде, чем чужом. Но из всех пяти программистов в час Х может быть доступен только один, а остальные будут жестко загружены на другом проекте. И ему придется переносить так же изменения своих коллег.

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

    Reply
  8. zaoallat

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

    «вот статейка » классная. Рекомендую.

    Reply
  9. andmakarov

    (8) WalterMort, в статье не подчеркнут один момент.

    Имеется в виду работа в виде Бизнес-Заказчик — Консультант 1С — Программист.

    Где консультант общается с бизнес-заказчиком и пишет ТЗ для программиста. Соответственно программист его читает, задает вопросы и делает. Консультант может находиться как в фирме-интеграторе (франчайзи 1С), так и может быть в штате крупного конечного клиента (именно отдельный консультант по 1С, который может написать ТЗ).

    Вся статья рассматривается именно с позиции разработчика в этой цепи.

    Поэтому, отвечая на вопрос:

    «Метод двойного чтения ТЗ О_о. Чтения кем? Заказчиком? Или это заказчик ТЗ напишет а мы будем читать? Ха.»

    Читает ТЗ программист. Пишет консультант 1С.

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

    Reply
  10. Гость

    Хорошая статья, мне — нужная.

    Reply
  11. vspol

    спасибо автору! мне очень понравилось!

    Reply
  12. SinglCOOLer

    Автор бы еще шаблон экселя для расчета приложил, цены бы не было

    Reply
  13. pro-rok

    (10)andmakarov, Спасибо автору за статью. Я тоже, довольно давно, использую метод двойного чтения тз, просто не знал, что это так называется. На самом деле только после второго-третьего прочтения приходит окончательное понимание, даже если ты писал сам. Очень часто после второго прочтения переписывал некоторые пункты ТЗ заново. Конечно здесь идет речь о больших ТЗ, я так понимаю часов от 50-70 и выше, такие ТЗ умещается страниц на 10, охватить умом подобную доработку не очень легко.

    Reply
  14. i_volodin

    (6) SaperVodichka, Простите за пошлость, но не удержался. Вы пишите цитирую

    «Обычно в комментарии ставят номер обращения клиента (в ходе сопровождения), либо номер ТЗ или ТП (в ходе разработки, внедрения).

    » А я как раз пишу в комментарии к коду номер заявки и фамилию ТП (заявителя) =)

    Reply
  15. sapervodichka

    (14) pro-rok, ))) у меня последние пять задач, были, наверное с ТЗ размером 40-100 страниц каждое

    Reply
  16. pro-rok

    (16)Ваши клиенты читают тз на 100 страниц или просто подмахивают?

    Reply
  17. sapervodichka

    думаю подмахивают )))

    Reply
  18. AZel84

    «Для быстрой оценки должен быть уже готовый специальный файл Excel»

    А можно получить файл-шаблон? Ссылкой или за стартмани.

    Reply
  19. Makushimo

    Пошел гуглить что такое этот JIRA :-))))

    Reply

Leave a Comment

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