Разработка и бизнес

Великий философ Гераклит наиболее известен своим высказыванием "Постоянны только перемены". Оно бы прекрасно подошло для эпиграфа к разработке программного обеспечения. Из-за несметного количества изменений технологий и языков нетехнические уроки разработки могут остаться без внимания.

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

• В большинстве случаев, основную роль играют детали. Умение укладываться в конечные сроки, создавать код с минимальными ошибками и выпускать исправное ПО помогают повысить уверенность у внешних заинтересованных сторон. Десять небольших улучшений всегда лучше, чем одно крупное изменение.


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


• Признавайте вероятность и вовремя обнаруживайте устаревание продукта. Часы начинают тикать с момента выпуска программы. Будьте проактивны и продумывайте действия в соответствии с обстоятельствами. Microsoft является примером компании-разработчика ПО с большим послужным списком случаев завершения поддержки с течением времени.


• Придерживайтесь подхода "В первую очередь ‘большие камни’". Не избегайте трудных задач в проекте. Беритесь сперва за них. Таким образом, вы сможете заранее определить проблемы и предоставить тщательную оценку оставшейся работы (ведь маленькие задачи оценивать легче).


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


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


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


• Не стоит пренебрегать другими аспектами работы. Если судить по заданиям (делить их на "хорошие" и "плохие"), можно поставить под удар возможности. Ищите сферы совершенствования, стремитесь стать специалистом в конкретной области и расширяйте свои знания.


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


• Пересматривайте процесс, код и функциональность. Можно внедрить концепцию бережливой или гибкой разработки. Кроме того, категоризация и отслеживание технического долга позволит улучшить видимость и даст пищу для обсуждений. 

источник