Проблемы, которых можно избежать
Наверняка, при внедрении различных информационных систем Вы сталкивались со следующими ситуациями:
1
Можно было и лучше
После завершения разработки программного продукта Вы видите лучшие варианты решений для него?
2
Нет возможности изменить ТЗ
Уже в ходе разработки программного продукта видите лучшие варианты, но нет возможности изменить техническое задание?
3
Ошибки
После запуска программного продукта в эксплуатацию в нем обнаружились логические ошибки?
К сожалению, многие компании часто сталкиваются с подобными проблемами. Обычно это происходит в проектах, когда компании заказывают разработку у сомнительных или недобросовестных разработчиков. Проблема, также часто кроется в жестком техническом задании, отступать от которого клиент или разработчик не захотели.
Наш подход к работе
Требования изменяются в процессе работы над проектом? Это нормально.
Очень часто нужно сделать один функционал вместо другого. Если мы видим, что изменение требований не приводит к увеличению времени на разработку, то мы не требуем дополнительной оплаты с заказчика.
У нас за плечами богатый опыт, десятки успешно реализованных проектов. Всё это позволяет нам первыми замечать детали, зачастую неочевидные для наших клиентов. Если по ходу работы мы понимаем, что можно ту или иную задачу сделать лучше, то мы немедленно согласовываем возможные изменения с заказчиком.
Зачем нам это? Потому что мы хотим делать лучшие продукты!
Жесткое следование техническому заданию
Не всегда можно работать по схеме, описанной в предыдущем разделе. Государственные структуры, крупные коммерческие предприятия – у них существуют многоступенчатые схемы согласования и принятия решений. В таких случаях оперативно вносить изменения в утвержденное техническое задание просто невозможно. Методика работы для таких проектов выглядит иначе: мы выполняем работы по первоначальному техническому заданию, а затем заказчик формулирует техническое задание на улучшение и эти улучшения нами реализуются. Конечно, издержки для клиента в этом случае выше, время до полного завершения работ над проектом больше. Но такой вариант тоже имеет право на жизнь.
Проект без технического задания – самый короткий путь к проблемам
В этом разделе хочется рассказать, как мы НЕ работаем. Обязательным условием для начала работ является наличие технического задания. Несколько раз мы отступали от этого правила и каждый раз впоследствии приходили к выводу, что это была ошибка. Представьте, что Вы пригласили домой строителей делать ремонт. И обговорили только цену, а задание сформулировали так: «Мне надо сделать ремонт в квартире». Можно гарантировать, что для Вас и для тех, кто делает ремонт, эти слова значат совершенно разные вещи, у вас будет разное мнение о том, что нужно сделать, какой фронт работ. Без технического задания невозможно однозначно определить, что исполнитель выполнил все свои обязательства перед заказчиком. Наступит момент, когда исполнитель будет считать, что все работы выполнены, а у Вас будет еще длинный список того, что, по Вашему мнению, необходимо реализовать. Как результат – конфликты, взаимные претензии. Всё это не идёт на пользу совместной работе, шансы на успешное завершение проекта уменьшаются.
Мы хотим продолжительных и счастливых отношений с нашими клиентами. Поэтому мы и не работаем без чёткого технического задания. В случае, когда клиент не готов сам составить техническое задание, мы берем это на себя.
Для нас Вы – полноправный партнер
Мы – профессионалы в создании ИТ-решений. Вы обладаете уникальными знаниями в своей сфере деятельности. Объединив наши усилия мы можем работать максимально эффективно и добиться наилучшего результата. Поэтому, мы всегда объясняем нашим клиентам наши подходы и методологию: чего ожидать заказчику и что от заказчика ожидаем мы, пытаемся вовлечь в работу над проектом на постоянной основе. Для нас заказчик – это партнер, который, имеет полное право отслеживать состояние дел, принимать участие в планировании задач, иметь доступ к промежуточным версиям продукта.
Как достичь результата
Чаще всего у заказчика весьма слабое представление о процессе разработки и внедрения программных продуктов. Наша задача – рассказать даже потенциальному клиенту, каким образом прийти из точки А, когда у него нет ничего, в точку Б, когда у него есть работающий продукт. Не только рассказать, но показать и, безусловно, дать рекомендации, что делать стоит, а чего делать не стоит.
Предпроектный ИТ-консалтинг
Все важные моменты мы согласовываем с клиентом в ходе предпроектного обследования и создания технического задания. Мы всегда рекомендуем нашим клиентам начать проект именно так. Такой подход исключительно эффективен, потому что, чем больше времени инвестируется в разработку качественного технического задания, тем меньше будет потрачено сил и средств на сам проект.
При использовании заказчиком наших консалтинговых услуг схема работы по проекту может выглядеть следующим образом:
- Предпроектное обследование
- Разработка технического задания на решение
- Приемо-сдаточные испытания
- Опытная эксплуатация
- Перевод в промышленную эксплуатацию
- Сопровождение и техническая поддержка
Критерии оценки эффективности ИТ-консалтинга
Насколько эффективно для клиентов привлечь нас в качестве консультантов на ранней стадии проекта? Мы каждый раз проводим анализ нашей работы чтобы получить количественную оценку. Цифры очень разные, в среднем, это один к восьми, т.е. один час на этапе консалтинга экономит 8 часов на этапе разработки.
Бывают, конечно, совершенно особенные проекты: на первоначальном этапе можно потратить 2 часа при создании технического задания, которые сэкономят 200 часов в ходе проекта. Если Вам интересно, как мы разрабатываем и внедряем наши программные продукты, обращайтесь, мы предоставим Вам самую подробную информацию. Расскажем обо всех этапах, покажем наши «дорожные карты», проведем по всей цепочке – от разработки технического задания до гарантийного сопровождения и технической поддержки уже запущенной системы.