Разработка ПО как процесс

Самое приятное дело – писать код “для себя”. К сожалению, есть одна проблема – получить денег за это не получится. По крайней мере, не получится получать деньги постоянно и регулярно (допускаю, что продать код, написанный “для себя” один-два раза получится).

Что же отличает разработку для собственного удовольствия от промышленной разработки ПО? Да примерно то же самое, что отличает мастера-горшечника от промышленного автомата, штампующего чашки и тарелки. Во-первых, это объем. Одно дело, написать одну программу за год-два. Другое – делать это постоянно. Хорошо если у мастера есть имя и его продукция расходится по баснословной цене, покрывающей все его расходы на несколько лет вперед. А если нет? Да и конкуренты не дремлют… Во-вторых, это Заказчик. Для себя можно долго “дотачивать” продукт до совершенства. Но Заказчик хочет получить не только качественный продукт, но и получить его к определенному сроку и за определенную (часто оговоренную заранее) цену. В-третьих, это команда. Небольшую программу можно создать одному, но сделать большую, многофункциональную систему (например, MS Office) одному  и в разумный срок не получится.

Итого, можно сформулировать такие цели разработки ПО:

1.       Получение прибыли.

a.       Программу нужно разработать в определенный срок. Заказчик не захочет ждать “вот как только допишем, сразу отдадим”. Заказчик готов ждать, но ждать понятный и разумный срок. Да и увеличение срока будет увеличивать расходы на разработку программы (зарплата, офис, оборудование) и эти расходы “съедят” всю прибыль.

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

2.       Заказчик должен быть доволен

a.       Программа должна решать проблему Заказчика. Иначе он просто не будет ей пользоваться. Даже если мы получим за это денег, то он к нам больше не вернется и не приведет новых клиентов.

b.      Программа должна быть качественной. Если программа работает, но постоянно “падает”, то сомнительно, что Заказчик будет доволен.

c.       Заказчик должен захотеть заказывать новую функциональность именно у нас. Такая доработка должна иметь разумную цену и не быть завышенной. Довольный Заказчик приведет новых клиентов.

3.       Команда должна быть довольна

a.       Если в процессе разработки команда разбежалась, то кто будет дорабатывать продукт и приносить новую прибыль?

b.      Если продукт настолько некачественно написан, что понять код могут только те, кто его написал, то проблемы в доработке обеспечены – рано или поздно “старикам разработки” этот продукт надоест, и они либо уволятся, либо попросятся на другой проект.

Каждый из этих трех пунктов важен. Отсутствие хотя бы одного означает не качественный проект и ставит под угрозу будущее компании-разработчика.