Правила оформления «Заявки на создание программного продукта»

Ранее мы писали о том «Зачем нужны «Заявки на создание программного продукта». Сейчас поговорим о том, как заполнять заявки и что нужно предусмотреть в их заполнении.

При формировании заявки исполнителю на доработку важно:

1. Понимать какой необходим конечный результат от доработанных механизмов.

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

2. Структурировать информацию.

Расписать детально заполнение каждого поля отчета, печатной формы. Какие есть отборы и условия по заполнениям. Зачастую заказчик пишет только прямое заполнение, и не предусматривает варианты заполнения «А как заполнять если ...?». А на вопрос:

                - Как заполнять если будет такая-то ситуация?

           Всегда в ответ слышишь:

                - Это крайне редко бывает. Практически никогда

                - Ok. Не вопрос. Тогда если будет такая ситуация программа не будет корректно работать. Вас это устраивает?

               - Нет.

               - Тогда скажите как заполнять.

               - А я не знаю, придумайте сами. Вы то лучше знаете программу….

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

И когда заказчик говорит: «Я не хочу платить за время, потраченное на написание заявки, я сам ее напишу. Дайте мне шаблон». Мы не пытаемся ему доказывать, что зачастую, если нет отдела аналитиков у которого есть опыт постановки задач, то его на самостоятельном написании заявки он не сэкономит, а только еще больше потратит времени и ресурсов. Если доказывать, он это «не услышит», пока сам не оформит заявку, на заполнит ее должным образом и не получит в ответ пару десятков вопросов, или если полностью доверимся ему и сделаем как он напишет, то через месяц окажется что он забыл предусмотреть какой-то вариант. Поэтому любая экономия на написании заявки и попытка минимизировать качество ее заполнение, проработка заполнения каждого поля со всеми возможными вариантами заканчивается тем, что через время заказчик обращается с претензией что не работает отчет. И приходится снова оформлять заявку, но уже детально все прописывать, дорабатывать сделанное. А иногда и «с нуля» все разрабатывать.

3. Назначить ответственного за контроль выполнения заявки и сроки проверки выполненной работы.

Со стороны заказчика всегда должно быть ответственное лицо, которое проверит выполнение заявки, протестирует ее во всех возможных ситуациях и даст согласие на принятие работ. Это важно по той причине. Что разработка программных решений по заявке заказчика тоже имеет гарантийные сроки. Если в течении, к примеру, 5 дней от заказчика не поступило возражений по качеству выполненных работ, то работы считаются приняты. Потому что бывают ситуации, когда заказчик оформил заявку, все сделали по ней и установили. Заказчик работает пол года, а потом к примеру увольняется сотрудник который работал с этой доработкой и новый сотрудник пишет исполнителю «Все пропало….». Ничего не работает, или работает не так как нужно, а как нужно никто не знает. Поэтому должен быть ответственный который в краткие сроки, пока все помнят в чем суть заявки и что по ней сделано проверит ее выполнение и даст подтверждение или дополнительные пожелания. 

4. Цена вопроса.

Перед оформлением заявки заказчик должен для себя понимать цену, которую он готов заплатить за свои желания. Он не всегда должен понимать цепочку формирования цены, как мы не задумываемся почему зубная щетка стоит к примеру 30 грн, и сколько в ее стоимости торговой наценки, растаможки, доставки, зарплаты кассира….. Так и здесь, заказчику не обязательно знать все процессы формирования затратной части и какие прямые и непрямые расходы входят в стоимость. Ему для понимания даже предварительной стоимости необходимо понимать основные этапы, которые проходит его заявка. Это:

- анализ, детализация и согласование заявки;

- предварительная оценка стоимости работ, с проработкой логики с точки зрения программирования;

- согласование стоимости работ по заявке;

- непосредственное выполнение работ по заявке, с выполнением всех требований разработчика программного обеспечения;

- тестирование выполненных работ;

- подключение всех доработанных механизмов к базе данных заказчика;

- при необходимости написание инструкций;

- проверка и принятие работ со стороны заказчика.

Вот так, казалось бы, сколько стоит добавление какой-то печатной формы, там работ на пол часа, добавить только одно поле(с точки зрения заказчика). А если пропустить хоть один пункт, то работа будет выполнена не качественно, а это равносильно что просто не выполнена. Если бы Илон Маск не следовал правилам прописанным его научным отделом, а делал то что хотят инвесторы, с их слов, то Теслы сейчас не только в космосе, но и на земле не было бы.

Да, эти все правила удорожают выполнение работ, но люди ездят уже не на "Жигулях" и машины ремонтируют не по домам каждый сам. Ведь немного другие скорости, и понимаешь, что если сам надумаешь отремонтировать машину, то можешь в самый неподходящий момент «слететь с дороги». Все чаще едем на проверенные СТО, а не к «Дяде Васе». Так и программное обеспечение, это не «Жигули», это совсем другой уровень, но все еще есть те, кто с современного программного обеспечения хочет сделать «Жигули».

Сейчас читают - "Бесконтактное общение - новый тренд в автоматизации бизнеса"

Начиная от элементарного, от правил работы с по заявкам и заканчивая крупными разработками мы вывели уровень работы наших специалистов на такой уровень, что только наши разработки GES ЗЕРНО КОРП и СОФТІНФОРМ. ERP УПРАВЛІННЯ ОЛІЙНОЕКСТРАКЦІЙНИМ ЗАВОДОМ единственные, которые получили сертификаты "Сумісно з програмами BAS". А это означает что они соответствуют всем требованиям разработчика. И если заказчик хочет, чтобы его программное решение упрощало ему жизнь, а он не ждал, когда и что перестанет работать, потому что он нашел дешевле, и при этом соответствовало всем нормам, он идет к нам, а не к тем, кто делает «заплатки», ставит «костыли» и «пишет на коленке».

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