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

  • Это не в прямом эфире на производстве
  • Он не был развернут
  • Никто другой не может его использовать

В том или ином случае мы все виноваты, в том числе и я. И мы не виноваты в этом. Мы не лжем о создаваемом программном обеспечении, у нас просто другой взгляд на это.

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

Позволь мне объяснить.

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

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

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

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

В этой работе есть разница между «разработкой» и «доставкой».

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

Ну что же, мы разрабатываем софт?

НЕПРАВИЛЬНЫЙ.

Мы поставляем программное обеспечение.

Разработка программного обеспечения - неправильное название для любого, кто не является разработчиком. Единственное, о чем заботится бизнес (и это правильно), - это поставка работающего программного обеспечения. Нам действительно следует называть себя поставщиками программного обеспечения.

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

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

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

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

Вся ценность программного обеспечения заключается в доставке. Фактическое развитие - это необходимая, но относительно небольшая часть этого. Как инженеры, мы можем давать более точные оценки и вести более продуктивные беседы с заинтересованными сторонами, уделяя особое внимание аспекту реализации того, что мы делаем. Это сложно, так как вам придется сознательно сопротивляться искушению рассматривать только логическую головоломку.

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

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

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