Разработка программного обеспечения на заказ

Разработка ПО на заказ – то, чем я занимаюсь много лет, большая часть из которых была работой по найму. А вот какое-то время назад решил попробовать самостоятельно сделать что-то доброе и, ПО максимуму, долговечное. Говорил мне как-то мой бывший начальник про мои новаторские идеи: «Валера, вот будет у тебя своя фирма, вот в ней и будешь устанавливать свои правила и реализовывать свои идеи». А в сущности, почему бы не попробовать. Ну а дальше я опишу некоторые принципы, в соответствии с которыми я разрабатываю программное обеспечение на заказ.

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

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

Например, одно кадровое агентство вело учет в MS Access. И их как-то не устраивало, что анкеты соискателей приходилось перебивать вручную в свою систему, и захотели они весь функционал перевести на WEB, чтобы соискатели сами забивали анкеты не как хотят, а строго в соответствии с требованиями веб формы. За много лет они себе довольно большой функционал написали на VBA Access. Перенос занял бы много времени и денег, а деньги, это то, с чем заказчик, к сожалению, расстается очень неохотно. Ну и предложил я им: раз вам нужно, чтобы соискатели сами вводили анкеты через веб форму, а все остальное, в принципе, устраивает в MS Access, давайте, я вам эту форму на вебе сделаю и интегрирую с MS Access. Будет дешевле, и вам переучиваться на другую систему не придется. На том и порешили.

Или же какой-нибудь Яндекс или Google предлагает свой сервис и API для расчетов много чего, например, предлагает решение задачи коммивояжера на своих картах. Да, их сервис стоит денег, но вменяемых, своя разработка будет стоить дороже. Так почему бы не использовать их сервис для быстрого и качественного решения?

Для снижения рисков я также использую классические технологии реализации IT проектов.

Несмотря на то, что эти технологии давно доказали необходимость своего применения, следуют им далеко не всегда. Иногда правильные подходы к разработке ПО игнорируют в силу недостаточной квалификации разработчиков ПО, но чаще всего небольшие компании подрядчики понимают, что несоблюдение технологий разработки повышает риски неуспешного завершения проекта, однако сознательно идут на риск в надежде сэкономить на стоимости проекта и влезть любой ценой, потеснив более консервативных и ответственных конкурентов. Собственно, один из моих работодателей именно таким авантюристом и был. И мои попытки убедить свое начальство в том, что нельзя подписываться под априорно убыточным проектом не имели на него влияния. Так как мой начальник лицо наемное, ему нужно реализовывать свой KPI, ему нужно делать продажи. То, что через год эта продажа превратится в зафиксированный убыток – в расчет можно не брать, бонусы через полгода. А через год, возможно, компания будет уже с другим руководителем.

В таких случаях принято говорить: «Скупой владелец платит дважды». Причем, относится это не столько к подрядчику, сколько к заказчику. Заказчик-то тоже теряет и время и деньги на неуспешный проект. Когда мне заказчик говорит, что то, что он хочет, другой программист, или другая компания готова сделать в два, в три, а то и в пять раз дешевле… Вы только представьте, я программист, ИП, упрощенное и облегченное налогообложение, у меня нет начальников и прочих непроизводственных затрат, и мне говорят, что какая-то фирма обещает сделать уникальный продукт в пять раз дешевле, чем я… Так вот, когда мне говорят про такие вещи, я не кручу, конечно, перед заказчиком пальцем у виска. Я сажусь вместе с ним, показываю ему план работ со списком задач, сроками и трудоемкостями. И спрашиваю заказчика: есть ли у моих конкурентов такой же план? Понимают ли мои конкуренты, то, за что они хотят взяться? Иногда заказчик встречается понимающий, иногда он даже говорит, что часть работ я поставил в план зря, и в таких случаях, мой прайс сокращается на некоторую сумму, а в договоре четко прописывается, какие работы мной не делаются. А иногда заказчик говорит так: « Да меня не волнует, как они будут решать поставленные в ТЗ задачи, хоть чучелом, хоть тушкой, это их проблемы ». И вот тут, как показывает практика разработки программ, заказчик не прав – неуспешный проект – это проблема заказчика . Во-первых, ТЗ сырое, и трактовать его можно по-разному (адвокаты потирают руки). Во вторых, если подрядчик не реализует задачу, то заказчик и время потеряет, и свои трудовые затраты спишет в никуда.

Медалист граблевед

Что интересно. Иногда встречаются заказчики, которые готовы много раз наступать на одни и те же грабли. Поэтому когда мне какой-либо потенциальный заказчик говорит, что есть задача, с которой не смогли справиться уже три программистские конторы, или три программиста, я понимаю, что здесь нужно быть очень внимательным, вполне возможно, дело не программистах, а в заказчике.

Так что же это за волшебные технологии успеха? В чем же заключается «секрет Полишинеля»?

В большинстве случаев клиенты первоначально ставят задачи в весьма размытой форме, при этом требуя от потенциального подрядчика (например, от меня) точной оценки сроков и стоимости. Многие подрядчики в таких случаях сильно перезакладываются в стоимости и в сроках разработки. Я не люблю перезакладываться.

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

В общем случае фазы следующие:

  • Подготовка документа «Бизнес-требования» заказчика
  • Описание существующих бизнес-процессов «As-Is» - то, как процессы выглядят сейчас.
  • Описание бизнес-процессов «To Be» - то, как процессы должны выглядеть после автоматизации.
  • Подготовка высокоуровневой спецификации решения, по сути дела технического задания на языке заказчика, в котором отражены критерии приемки проекта, т.е. исчерпывающий перечень вариантов тестирования. В рамках этого же этапа готовится план проекта, согласовываются стоимость и сроки, масштаб (что делать будем) и ограничения (что делать не будем) проекта.
  • Собственно, разработка.
  • Если в договоре прописано и в стоимости работ учтено, то в ходе разработки помимо кодов создается целый список технических спецификаций, которые делают результаты моей работы отчуждаемыми. При соответствующем оформлении прав на результаты разработки заказчики могут передать коды на доработку другим подрядчикам, и другие подрядчики получат документируемые результаты моей работы.
  • Опытно промышленная эксплуатация, обучение пользователей.
  • Поддержка созданного решения.
  • На протяжении всего проекта создаются проектные документы, позволяющие заказчику быть в курсе того, какой процент от общего объема работ выполнен, какие проблемы возникли в ходе работы над проектом, какие запросы на изменения появились и т.д.

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

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