«вовремя» или «качественно»?
Первая проблема, с которой сталкивается любой программист – утверждение времени выполнения проекта. Легко устанавливать дедлайн, управляя рабочими на заводе. Но программист – не просто исполнитель заказа. При написании софта фактически приходится выбирать: получить продукт вовремя или в наилучшем качестве. Именно «или» - третьего не дано. Выполнение обоих условий одновременно – что-то из разряда фантастики. Есть исключительные случаи, но их слишком мало. И этому есть объяснение.
Сроки в программировании?
Качественный софт и четкое временное планирование – несовместимые понятия? Сложный вопрос, продиктованный опытом. Достаточно вспомнить проекты, сделанные на совесть. По скольким из них были сорваны сроки? Однозначно – почти по всем.
Обычно перед исполнителем стоит задача – успеть. Уложиться в отведенные сроки во что бы то ни стало. Сдав заказ точно в оговоренные временные рамки, программист выполняет его лишь формально. Такой проект – сборник «косяков» и недоработок, а иногда и вовсе провальная идея. Продукт неудобен или просто не работает. Как итог – часы и дни работы по исправлению кода, иногда - написание софта с нуля из-за отсутствия перспектив получившегося «творения».
Есть проекты с гибкими сроками сдачи. Нет, в них все-таки определен дедлайн, но его временные границы размыты. Опыт показывает, что в таких условиях создается более качественные прикладные программы. Довольны и заказчик, и исполнитель. Но стоит ли говорить, насколько редки такие проекты?
Креативность, мастерство и непредсказуемость – друзья профессионального программиста. Они позволяют «выдать» качественный продукт, но просто ненавидят жесткие временные рамки. Разберемся, почему.
Программирование и креатив
Программирование – это творчество. Услуги программиста – это выполнение незаурядных задач. Конечно, встречаются «шаблонные» виды деятельности и тривиальные задания, но речь не о них.
Работа на серьезном уровне предполагает генерацию идей и поиск нестандартных решений. Именно от творческой составляющей программист получает удовольствие. Создавать нечто новое сложно, но безумно интересно. А вот выполнять простой набор инструкций – не совсем. Чем больше простора для творчества, тем больше увлекает работа, тем оригинальней готовое техническое решение.
Будучи творческой работой, программирование не может существовать без метода проб и ошибок. Невозможно увидеть идеальное решение, не начав писать код. Каждая идея проходит проверку практикой. Какой бы уникальной ни была задумка, возникают недочеты и недоработки. Правка – время, поиск нового решения – снова время.
Невозможно смоделировать процесс создания софта на бумаге – наработки так и останутся теорией. На практике возникнут новые проблемы и вызовы, о которых не может знать наперед даже самый опытный аналитик. Работа программиста – импровизация, создание и проверка гипотез. Эта деятельность не сочетается с жесткими временными рамками.
Иногда полезнее отложить выполнение проекта, чем сдать его в вовремя. Человеческий мозг не генерирует оригинальные идеи по приказу извне - поиск решения идет параллельно с другими видами деятельности. Решение возникает неожиданно (естественно, если человек обладает мотивацией к его поиску). Это можно сравнить с программой, работающей в фоновом режиме и периодически присылающей уведомления. Но далеко не все заказчики понимают, что отказ от срочного выполнения работы скорее пойдет на пользу. Более того, они уверены в обратном.
Работа мастера
Легко создать софт, который работает. Сложно создать софт, у которого будет не только настоящее, но и будущее – в этом состоит задача мастера. Качественный проект должен пройти проверку временем. Уровень мастерства определяется качеством работы. Количество выполненных проектов не имеет значения, если ваш код – повод посмеяться и показать, как делать не стоит. Можно написать программу в рекордные сроки, попутно наделив ее приятным внешним видом. Но работать она будет так, что вас не раз вспомнят недобрым словом. Для создания хорошей программы нужно немало времени. Высокие требования к качеству продукта автоматически вычеркивают из задачи фразу «сделать как можно быстрее».
Мастер заботится о тех, кто будет обслуживать и использовать его программу в будущем, делая качественный продукт. Эффект должен быть долгосрочным, но при этом заказчик просит написать программу побыстрее.
На деле требуется проверить несколько гипотез, прежде чем «выдать» идеальное решение. Сделать рефакторинг, обнаружив неудачный фрагмент кода. Полноценно протестировать продукт, а после – исправить недочеты. Если программист работает с коллегами, необходимо согласовать стратегию работы и обсудить каждый этап при выполнении проекта. Никто не знает, сколько времени на это потребуется. А значит – сроки предсказать невозможно. Но на практике срок выполнения часто оказывается первостепенным, качество – второстепенным.
Непредсказуемость
Компьютерные программы – сложные системы. Их элементы «впитывают» эмоции, мотивацию, проблемы и психологические барьеры людей, их создающих. Перечисленные составляющие невозможно смоделировать, а тем более – выразить количественно.
В программировании имеют место быть нелинейные реакции. Увеличивая одну переменную в N раз, вы ждете, что другая переменная увеличится в той же пропорции. Получается по-другому: эффект может быть как более сильным, так и более слабым.
Время – противоречивая категория. Проблемы проекта накапливаются ближе к дедлайну и почти отсутствуют на старте. Программа, близкая к логическому завершению, по уровню готовности может быть ближе к старту, чем к финишу.
Заказать программу – значит, гарантировать себе неопределенность при оценке времени выполнения задачи. Ошибка в прогнозе велика, даже когда дедлайн устанавливает сам разработчик. Если о времени выполнения проекта говорит человек, далекий от программирования, он правильно оценит временные затраты только по счастливой случайности.
Невозможно предсказать, какие результаты даст обратная связь, сколько времени потребуется на обработку полученной информации и как долго программист будет исправлять недочеты. Не исключено, что для получения результата понадобится несколько неудачных попыток рефакторинга кода. Стоит повторить – разработка прикладных программ требует времени.
Что делать со сроками?
Стремление предугадать дату сдачи качественной, полностью рабочей программы обречено на провал. Процесс написания прикладных программ непредсказуем. Мастеру необходимо концентрироваться на качестве прикладной программы. А как быть с требованиями заказчика?
Одно из решений проблемы – работа грамотного технического менеджера. Он сокращает разрыв в понимании между заказчиком и исполнителем. Это позволяет давать программисту определенную свободу действий, в том числе – гибкие сроки выполнения работы.
Еще одна составляющая успеха – наличие доверительных отношений между бизнесом и программистом. Зная о качестве работы мастера, заказчик с пониманием относится к переносу выпуска финальной версии. Он уверен, что на выходе получит достойный продукт. Но доверие нужно заслужить, что невозможно при работе по первому проекту с новым заказчиком.
В программировании не нужны конкретные временные рамки. Лучше, если срок выполнения будет варьироваться, например, в промежутке 4-6 недель, чем будет установлена крайняя дата. Так срыв сроков не воспринимается болезненно ни коллегами, ни самим исполнителем.
Программист – первый, кто заинтересован в техническом качестве продукта. Говоря о сроках, заказчик должен понимать, что у него и исполнителя одна общая цель. Полезнее объединить усилия, сделать работу более комфортной и продуктивной, а не жить конкретными датами.
Проблема сроков – одна из самых сложных в программировании. Но она решаема. Обе стороны должны быть заинтересованы в качественном программном обеспечении. Грамотный заказчик ставит на первое место качество продукта и только потом говорит о сроках. Сотрудничество строится на понимании и доверии. Такая работа – залог успеха.