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

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

Как вовремя осознать, чего как раз желает Клиент, и избежать подводных рифов на пути к цели? Вниманию разработчиков 1С — опыт «Нэти», одной из ведущих аутсорсинговых IT-компаний России.

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% и сходу»

Старайтесь заметить неясности и задать вопросы сходу по максимуму. Нахождение всех нестыковок в техзадании достигается тренировкой моделирования в уме технической реализации задачи. В отечественной IT-аутсорсинговой компании «Нэти» такие тренировки практикуют многие.

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

3. Способы утончения вопросов

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

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

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

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

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

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

При форс-мажорах вы либо ваши сотрудники смогут скоро поднять все данные.

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

Как свести к минимуму возможность оценки «от балды»? — корпоративный опыт IT-аутсорсинговой компании «Нэти»

1. Оценка по способу PERT. В отечественной компании разработчики 1С применяют оценку по способу PERT.

Эта оценка выполняется так:

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

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

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

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

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

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

Для стремительной оценки должен быть уже готовый особый файл 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. Завершайте на мажорной ноте. И основное! Фраза «В случае если будут вопросы по новому функционалу — пишите.

С удовольствием отвечу» никого еще не убила, но эффект от нее потрясающий – пользователь не нервничает, и исходя из этого лучше соображает при знакомстве с результатами вашего труда.

Финансовая жизнь

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

ТЗ от заказчика Нарисуйте нам 7 красных линий

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: