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

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С.рф