Как пишут программы? Разработка программного обеспечения — это комплексный, очень интересный и часто не менее сложный процесс, требующий особых знаний и подхода. Вспоминая, насколько противоречивые и опережающие время требования предъявляются к большинству сложных проектов, становится ясно, что создать в срок востребованное, функциональное и надежное программное обеспечение не так уж и легко.

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

Во-вторых, разработка проекта обязательно должна документироваться с самого начала. Более того, документация должна существовать не только в голове у менеджеров или разработчиков, но еще и на бумаге. Все спецификации должны находится в актуальном состоянии, отражающем реальное положение дел. В. А. Высоцкий из Bell Telephone Libraries заметил: «очень многие неудачи связаны именно с теми аспектами, которые были не вполне достаточно специфицированы».

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

Разумеется, кроме перечисленных фундаментальных принципов существуют еще и другие, не менее важные для успешной разработки и дальнейшего развития любой системы. Однако описать их целиком в рамках такого небольшого эссе не представляется возможным.

Проблемы и ошибки Одним из первых проблему организации разработки программных систем, а также задачу эффективного управления группами программистов начал изучать Фредерик Брукс, профессор вычислительной техники в университете Северной Каролины.

Еще в 1975 году в своей легендарной книге «Мифический человеко-месяц или как создаются программные системы» Брукс описал множество типовых проблем и заблуждений, с которыми рано или поздно сталкиваются менеджеры и разработчики IT-проектов, а вслед за ними и заказчики.

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

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

Хотя с 1975 года прошло уже более 30 лет, проблемы, описанные Бруксом, почти не потеряли актуальности. Счастье, что сейчас научились прежде создавать прототипы программ (действующие внешне, но не функциональные по сути макеты)! Это сильно упрощает изначальную оценку идеи, концепции и реализации, внешнего вида и удобства использования. Появилось множество новых методологий разработки, что позволяет создавать сложные системы быстрее и лучше, чем раньше.

Однако самую главную проблему никакая методология не в силах разрешить.

Большинство разработчиков и менеджеров планируют разработку программ на основе откровенно ложного утверждения: «все будет идти хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять». Отсюда сорванные планы, проваленные проекты и потерянные время, деньги, репутация. Специфика работы программиста подразумевает появление ошибок в процессе разработки, и это нормально. Ненормально лишь оставлять эти ошибки в финальной версии программы.

Уж не знаю, какой интуицией, прозорливостью и опытом нужно обладать, чтобы точно определить срок разработки программной системы!

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

Значит ли это, что качественно, быстро и по приемлемой цене разработать ПО не получится? Не совсем, и я объясню, как это удается.

Как добиться успешности проекта? В первую очередь, сначала я полностью проектирую, а только потом начинаю разрабатывать систему. На проектирование уходит около трети всего времени и усилий.

На этом этапе проясняется и решается очень много текущих вопросов, а вы лучше осознаете, за что уплачены деньги. Цена определяется на этом же этапе.

В функциональной спецификации (пример) полностью описывается текущая версия системы (и возможные расширения, вопросы и предложения) с точки зрения ее пользователя; максимально доступным и приятным для чтения языком.

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

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

При этом все серьезные и большинство мелких вопросов решаются еще на этапе составления документации и «всплывающие» в ходе разработки спорные моменты куда проще разрешаются; без ущерба для времени и нервов.

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

Свяжитесь со мной!

Post ScriptumСпасибо, что дочитали до конца! :) Эта статья не является всеохватывающей и достаточно подробной. Если затронутые выше вопросы показались вам интересными, рекомендую ознакомиться со следующими книгами: