Практически любой современной компании, вне зависимости от ее размера и годового оборота, требуются софтверные инструменты - программное обеспечение, обеспечивающее деятельность копании. К таким инструментам можно отнести системы управления взаимоотношениями с клиентами (CRM), системы управления содержанием web-сайтов (CMS), всевозможные системы складского и бухгалтерского учета, логистические системы и прочие инструменты, автоматизирующие определенные процессы в компании.
У руководителей компании часто возникает желание разработать требуемое ПО самостоятельно, силами компании, сформировав под это отдельную команду и выделив соответствующий бюджет. Поводом для такого решения может стать большая стоимость лицензий на нужный продукт, специфические требования, предъявляемые к нужному ПО, незнание рынка существующих средств автоматизации для конкретной отрасли. Кроме того, на путь самостоятельной разработки вас могут подтолкнуть наемные руководители подразделений или проектов, имеющие специфические амбиции, стремящиеся упрочить свое положение в компании, встав во главе нового проекта (или просто “подзаработать” за счет “откатов” от подрядчиков). Иногда решение начать самостоятельную разработку исходит от руководителя ИТ-направления, вышедшего из среды программистов - такие специалисты часто искренне любят сам процесс программирования и являются талантливыми кодерами, но не всегда сопоставляют свои таланты с потребностями бизнеса.
Причин может быть множество, но результат один - компания начинает самостоятельную разработку нужного ей продукта и почти гарантировано попадает в ловушку, выбраться из которой без потерь не удастся.
Процесс разработки ПО состоит из нескольких основных стадий, которые мы должны пройти, чтобы достичь положительного результата. Максимально упрощенно его можно представить так:
- постановка задачи и выработка требований к создаваемому продукту;
- написание технического задания (ТЗ) - документа, определяющего, что именно должно получится в результате разработки, какие функции должны быть у продукта и как именно они должны быть реализованы;
- написание кода продукта (программирование);
- тестирование продукта;
- ввод в эксплуатацию.
Техническое задание - не блажь, и не проявление бюрократизма. Этот документ является руководством, направляющим работу команды разработчиков, он же описывает ожидания заказчика и определяет критерии соответствия продукта этим ожиданиям. Отступление от ТЗ приводит к тому, что итоговый продукт может отличаться от того, что вы ожидали получить. Изменения, вносимые заказчиком (в нашем случае это потребители будущего продукта) в ТЗ по ходу работы могут перечеркнуть результаты многомесячного труда или по меньшей мере отбросить разработчиков на несколько шагов назад.
По мере выполнения пунктов ТЗ требуется тестирование уже готовых частей пишущейся программы, при этом к тестированию следует привлекать людей из числа будущих пользователей. Программирование и тестирование - это очень разные виды деятельности, поэтому для полноценного тестирования желательно привлекать отдельных специалистов, а не тех, кто участвовал в написании кода.
В момент запуска программы в «боевую» эксплуатацию обязательно вылезут недостатки созданного инструмента и просчеты, совершенные при его проектировании. К тому же, на момент выхода первой стабильной версии, как правило, уже возникает потребность добавить к продукту новые функции – аппетит приходит во время еды. Начинается второй виток разработки: требования, ТЗ, написание кода, тестирование, запуск новой версии.
Шуточный закон программирования гласит, что исправляя одну ошибку, программист всегда вносит в код две новых. Бизнес тоже не стоит на месте, поэтому через некоторое время после сдачи новой версии сам собой возникнет вопрос о продолжении работ над продуктом, исправлении ошибок и добавлении новой функциональности.
Таким образом, разработка ПО - бесконечный процесс, развивающийся по спирали. Остановить его может только отсутствие спроса на разрабатываемое ПО и прекращение финансирования. Софтверные компании, занимающиеся разработкой “коробочных” продуктов для массового потребления, финансируют разработку новых версий своих продуктов и поддержку выпущенных ранее версий за счет средств, вырученных от продаж разрабатываемого ПО. Если вы разрабатываете программный продукт для внутреннего потребления, следует задуматься о том, за счет каких средств будет финансироваться разработка.
Любые программные продукты создаются для повышения продуктивности бизнеса. Их использование должно сказаться на эффективности предприятия либо за счет увеличения выручки, либо за счет сокращения издержек (в том числе и потерь времени), а в идеальном случае - за счет обоих факторов. Если этого не происходит, такая автоматизация не имеет смысла. Если средств, дополнительно вырученных или сэкономленных за счет использования разрабатываемого ПО хватает лишь на поддержание самого процесса разработки (или не хватает даже на это), такая разработка также бессмысленна.
Запуск проекта по разработке требуемого для бизнеса ПО без тщательного прогноза будущих затрат и их сравнения с ожидаемым результатом - одна из наиболее частых ошибок всех “самодельщиков”.
Частное проявление этой ошибки - уверенность в том, что возможно единовременно потратить некоторую сумму на создание нужного ПО, после чего оно начнет приносить вам прибыль. Как уже было сказано ранее, разработка ПО - процесс бесконечный, поэтому самостоятельно разрабатываемый продукт требует постоянной финансовой подпитки. Следует иметь в виду, что прибыль, получаемая от использования “самодельного” ПО, может не покрыть эти затраты.
Второе фатальное заблуждение - отказ от “излишей бюрократии”: формального планирования работ, написания и согласования ТЗ и ведения рабочей документации. Далекие от ИТ и реалий разработки ПО руководители часто не осознают, что результат работы по написанию ПО напрямую зависит от того, насколько тщательно ведется документация и насколько сам процесс согласован с документацией. В итоге программисты либо получают задание в духе “пойди туда, не знаю куда” и “сделайте мне красиво”, либо заказчик в лице ключевых пользователей будущей программы постоянно дает новые вводные, зачастую взаимоисключающие.
Надо ли говорить, что в этом случае работа либо будет вестись бесконечно долго, и вы рискуете так и не увидеть версию программы, которой можно худо-бедно пользоваться ежедневно. Либо вы получите готовый продукт, написанный в соответствии с тем, как ваш бизнес понимают программисты, а не то, что нужно бизнесу на самом деле. В самом плохом случае вы получите и то, и другое, плюс разбежавшуюся команду программистов, сошедших с ума от работы в подобном бедламе.
Третья распространенная ошибка - попытка конкурировать с уже имеющимися на рынке продуктами. Мало кому приходит в голову разрабатывать для своей компании аналог операционной системы Windows, чтобы сэкономить на приобретении лицензий. Зато предостаточно примеров, когда компании тратили сотни тысяч долларов и годы в попытке создать свою собственную CRM- систему, систему складского учета или документооборота, вместо того, чтобы заплатить десятки за подходящий готовый продукт, который можно бы было внедрить за 1-2 квартала.
Стоит допустить одну из этих ошибок – и вы уже в ловушке. С одной стороны в разработку вложено немало средств, которых жалко. С другой стороны, есть надежда на спасение затянувшегося и вышедшего из под контроля проекта, но это требует дополнительных вливаний, объем которых оценить сложно. И вот уже вам остается либо смириться с уже состоявшимися потерями и прекратить разработку (после чего таки вложиться в готовый продукт), либо упорно продолжать тратить ресурсы в попытке достичь приемлемого результата. Само собой, чем дольше длится такой проект, тем больше ваши издержки и меньше вероятность, что их удастся возместить.
Бесспорно, далеко не каждое программное решение способно удовлетворить требования вашего бизнеса. Если ваше дело само по себе инновационно, вряд ли найдутся готовые программные решения для автоматизации имеющихся бизнес-процессов. В этом случае самостоятельные разработки и изыскания являются разумным выбором и чуть ли не единственным возможным выходом. Однако если ваш бизнес работает по общепринятым схемам, внутренние процессы более или менее стандартны, вряд ли имеет смысл изобретать велосипед. В этом случае будет разумным использовать готовые продукты, адаптированные под ваши нужды.
Таким образом, прежде чем встать на путь самостоятельной разработки программного обеспечния для внутреннего использования, следует ответить на следующие вопросы:
- чем вызвана необходимость в разработке ПО своими силами: насущной необходиостью, амбициями или скрытыми мотивами ваших сотрудников?
- сколько времени и средств вы готовы потратить на разработку?
- как ваш бизнес будет жить без нужного продукта все то время, пока ведется разработка?
- из каких источников будет финансироваться разработка?
- есть ли у вас резервы, чтобы продолжить разработку, если вдруг проект выйдет за рамки бюджета?
- через какое время после начала разработки должна выйти первая версия продукта, обладающая достаточной функциональностью для повседенвного использования?
- есть ли у вас человек, способный возглавить проект по разработке ПО и имеющий опыт подобной работы?
- имеете ли вы представление, сколько будет стоить содержание команды разработчиков в течение срока разработки?
- можно ли поручить разработку продукта специализированной компании, и сколько будут стоить их услуги?
- как вы оцениваете экономический эффект от использования продукта, который предстоит разработать (сколько он принесет денег)?
- достаточен ли он, чтобы не только окупить издержки разработки, но и принести прибыль?
- есть ли на рынке уже готовые продукты, отвечающие вашим требованиям или могущие быть доработанными при разумных затратах?
Ответы на эти вопросы дадут вам представление о своих целях, потребностях и возможностях. Это поможет вам понять, имеет ли смысл начинать самостоятельную разработку или стоит потратить силы и средства на внедрение готового продукта.
Источник: http://www.mednikov.ru/