На заре развития ИТ индустрии разработчики годами работали над своими продуктами в одиночку. И однажды их продукция захватила рынок и сделала своих создателей богатыми и знаменитыми. Конечно, это было заслуженно. Но стоит отметить, что это произошло не потому, что их продукция была лучшей, а скорее потому, что она была уникальной на тот момент.
Однако индустрия программного обеспечения быстро менялась, становясь все более обширной и сложной. Конкуренция росла, а борьба за внимание пользователей обострялась. Таким образом, рынок наполнялся все более и более качественными продуктами и услугами. И мы все больше привыкали к их постоянно растущему качеству и количеству. Теперь мы вообще не хотим идти на компромиссы, зная, что всегда можно найти что-то лучше.
Все это возможно благодаря тому, что в разработку вовлекается все больше профессионалов из разных областей, не только технических. Сейчас любой конкурентоспособный продукт — это совместная работа разработчиков, дизайнеров, аналитиков, маркетологов и менеджеров. Это лишь краткий список специалистов, которые нашли новый дом в индустрии программного обеспечения.
Например, когда Стив Джобс создавал Macintosh, он даже пригласил зоологов, разбирающихся в анатомии, чтобы они помогли ему найти оптимальные пропорции будущего устройства, идеально подходящие друг к другу.
Но чем больше специалистов задействовано в разработке программного обеспечения, тем больше процессов оно включает и тем сложнее ими управлять. И к каждому процессу нужно относиться с особым вниманием. Поскольку каждый из них может быть главным фактором успеха или неудачи будущего продукта, необходимо знать подводные камни разработки программного обеспечения в целом и, в частности, основные подводные камни управления проектами.
Важно уделять индивидуальное внимание каждому процессу разработки. От определения целей и наиболее подходящих средств для их достижения до использования лучших методов проектирования, разработки, тестирования и поддержки. И это внимательное отношение вызывает у клиентов желание обращаться к вам снова и снова. Ведь они всегда могут доверять прозрачности, гибкости, стабильности разработки и высокому качеству конечного продукта.
Недостаточная оценка
Индустрия
Как мы уже говорили ранее, любая отрасль переполнена солидными игроками и отличными предложениями. Если не учесть всех деталей, можно остаться незамеченным и потратить огромное количество времени и денег.
Стоит отметить, что это одна из самых распространенных ошибок при разработке программного обеспечения. Ведь наличие хорошей идеи может быстро заставить вас поверить в то, что вы исключительны. А наличие ресурсов для ее реализации может привести к поспешным решениям, сомнительным выводам и т.п.
Вместо этого было бы лучше, если бы у вас был глубокий анализ потенциальных конкурентов или партнеров и их возможностей, потенциальных клиентов и их потребностей, а также всей специфики индустриальной области, в которой вы хотите разрабатывать свой продукт.
Цели
Абстрактные цели не могут быть достигнуты. Процессы достижения этих целей потребуют бесконечного количества усилий, времени и денег. И результат будет либо отсутствовать, либо будет неоднозначным.
Если команда менеджеров и разработчиков готова взяться за такой проект, доверять им не стоит. Или у них недостаточно опыта, чтобы указать на пробелы. Или они недостаточно добросовестны и возьмут с вас как можно больше денег и времени, не заботясь о конечном результате.
Поэтому цели должны быть абсолютно конкретными, достижимыми и измеримыми. Так процессы можно полностью контролировать и приносить желаемые и ожидаемые результаты.
Средства
Если средства не соответствуют целям, их достижение либо весьма сомнительно, либо вообще невозможно. Ведь правильно определенные и используемые средства так же важны, как и сами цели.
Ловушка ошибочного выбора технологий часто преследует тех, кто плывет по волнам тренда и выбирает универсальную или популярную технологию, компоненты или инструменты. Такой выбор может привести к краху. Даже если цели поставлены правильно, работают специалисты высокого уровня, а времени и сил потрачено много, проект в таком случае становится технически невыполнимым.
Наоборот, выбору средств должно быть уделено не меньше внимания, чем определению целей. Процесс выбора требует всесторонней оценки технических специалистов, менеджеров проектов и бизнес-аналитиков. А когда цели строго согласованы со средствами и выбраны наилучшие возможные средства, у вас уже есть отличная деловая и техническая основа для успешного проекта.
Ресурсы
Без должной оценки бюджета даже самый перспективный проект может прекратить свое существование в любой момент.
Если не рационально распределить бюджет, проект может понести убытки еще до своего запуска и до того, как он начнет приносить прибыль. Первое, что может показаться незначительным - так это количество необходимых инструментов для работы и коммуникации. Затем, и это основное, - уровень и состав команды, проводимые исследования, тестирование и так далее. И все это будет все больше и больше ухудшать качество продукта и отодвигать дату выпуска.
Вместо этого лучше сразу прикинуть, какой бюджет потребуется на все предстоящие и возможные процессы. Оставьте резервный бюджет для непредвиденных расходов. И распределяйте его очень подробно, а также постоянно контролируйте его расходование.
Недостаточное отслеживание
Время
Без оценки времени не может быть ясности в том, что происходит.
Если оценка времени выполненной работы неточна, то нельзя говорить о каком-либо планировании и сроках выполнения задач, а также прочих аспектах. Кроме того без точной оценки времени невозможно использовать Agile-практики и такие инструменты, как Scrum и даже Kanban, а они принципиально важны в разработке программного обеспечения.
Любая достаточно развитая технология неотличима от магии. Поэтому необходимо вести точный и регулярный хронометраж по каждой задаче, сотруднику и проекту в целом. И тогда вы откроете для себя удивительные практики и инструменты, которые настолько точны, что вы сможете предвидеть или определить любой аспект рабочих процессов и немедленно повлиять на них.
Производительность
Без измерения производительности тайм-трекинг не раскрывает своего истинного потенциала.
Это частая ловушка управления проектами, когда устанавливаются сроки, устанавливаются графики, оценивается время. Но пока никто не соблюдает все сроки, никто не считает нужным измерять производительность.
Больше всего удивляет то, что вы уже можете почти автоматически измерять производительность с помощью отчетов в таких сервисах, как Jira, измеряя время. Вам нужно интерпретировать доступные метрики и верно определить что нужно сделать. Вы можете не только все сделать вовремя, но и заранее обнаружить риски превышения сроков. Выявляйте блокираторы, тормозящие разработку, в виде плохо описанных или распределенных задач, ненужных или отсутствующих процессов, внезапных сложностей и отдельных членов команды и т. д.
Недостаточная коммуникация
Каналы
Не следует использовать обычные каналы связи.
Очень распространенная ловушка — когда социальные сети и мессенджеры используются для профессиональных нужд. Это может показаться хорошим решением, потому что они бесплатны, удобны и у каждого есть там учетная запись. Но они могут быть неэффективными, нефункциональными или просто недостаточно безопасными.
Используя личные профили, сотрудники путают свои личные и рабочие разговоры, часто могут пропустить важное сообщение от коллеги и так далее.
Также обычные мессенджеры не обладают достаточно широким функционалом для анализа и улучшения коммуникации, особенно если речь идет об интеграции третьих лиц или внедрении пользовательских компонентов.
И, конечно же, только использование корпоративных аккаунтов и соответствующих каналов связи может дать вам необходимую степень контроля и безопасности данных. Ведь даже владелец личного кабинета может не знать, что его взломали и украли его данные.
Вместо этого используйте только корпоративные учетные записи для электронной почты и других служб, которые предоставляют вам доступ к данным компании и проекта. А также подходящие каналы связи, такие как Slack, в котором много возможностей для рабочего общения и множество интеграций.
Встречи и созвоны
Без совещаний качество общения становится принципиально ниже.
Это ловушка в управлении проектами, которая таит в себе двойную опасность. Это как покрытый водорослями подводный камень, о который можно не только разбиться, но и подскользнуться.
Ведь процессам может навредить как отсутствие встреч, так и их избыток. То есть чисто асинхронное общение может вызывать чувство подавленности, апатии и другие неприятные психические проблемы.
Также асинхронная коммуникация может вызвать некоторую путаницу в распределении задач, обязанностей и прочего, если их не озвучивать в одном месте и в одно время для всех.
Избыток совещаний может отнимать слишком много времени. Команда может попасть в ловушку, постоянно обсуждая решения проблемы, ища лучший способ вместо того, чтобы попробовать сделать хоть что-то.
Кроме того, избыток совещаний может внести двусмысленность в распределение задач и обязанностей, когда они перераспределяются несколько раз в неделю во время очередного обсуждения. Участникам проекта необходимо изменить фокус, а изменение фокуса также требует отдельных усилий и времени.
Лучшее решение — правильное сочетание синхронной и асинхронной связи. Это сэкономит огромное количество времени, сделает разработку стабильной, прозрачной и эффективной, а также поддержит психологическое состояние участников проекта.
Стандарты
Без общих стандартов не может быть общего понимания.
Это частая ловушка при разработке программного обеспечения, особенно в молодых компаниях. Все хотят быть похожими на Google, где все общение и работа в целом кажутся такими вольно-непринужденными.
Но на самом деле это может быть так только в отдельных случаях, а не в целом. В противном случае может возникнуть множество неоднозначных ситуаций, недоразумений и даже конфликтов. Например, стандарты могут включать запрет на использование неприятных или непонятных сокращений, провокационных или ложных утверждений и так далее.
Именно поэтому стандарты работы и общения незаменимы, ведь без них вы тонете в буре, и никакие маяки на горизонте не смогут вывести вас из нее.
Недостаточная экспертиза
Аналитики
Недостаточно компетентные аналитики могут недооценить или переоценить проект.
Такой подводный камень неочевиден. Ведь когда люди думают о качественном продукте, они думают о разработчиках. Но от аналитиков зависит, насколько успешным будет продукт. И если они недостаточно компетентны, это создает проблему в самой основе проекта.
Анализ рынка, конкурентов, партнеров и потенциальных результатов исследования проекта может быть неверным. И даже если результаты верны, их интерпретация и основанные на них прогнозы могут быть ошибочными. Это проявится в неправильном распределении бюджета, определении целей и средств, состава и уровня команды и всего остального.
Поэтому аналитики должны быть максимально конкурентоспособными в своей области, желательно и в смежных областях.
Менеджеры
Некомпетентные менеджеры могут провалить любой проект.
Подводный камень здесь тот же, что и в предыдущем случае. Руководители проектов играют одну из ключевых ролей в разработке программного обеспечения. А если их компетенций недостаточно, то неважно, насколько велик потенциал проекта, насколько хороши инструменты и насколько квалифицированы разработчики.
Потенциал проекта не будет полностью раскрыт. Ресурсы будут потрачены не лучшим образом. И у разработчиков будут постоянные проблемы со своевременным выполнением задач, установлением правильных сроков их выполнения и многими другими сложностями.
В итоге у вас будет корабль, где все гребцы гребут в разные стороны, ломая весла о скалы и постоянно попадая в бури.
Поэтому руководители проектов должны быть максимально конкурентоспособными. Им нужно обладать достаточными техническими, аналитическими и гуманитарными навыками, чтобы говорить на одном языке со всеми, от разработчиков до заказчиков.
Дизайнеры
Недостаточно компетентные дизайнеры могут нарушить функциональность продукта.
Эта ловушка больше похожа на айсберг. Ведь многие до сих пор относятся к дизайну как к красивой картинке, которая делает продукт ярче остальных. И похвально, что подавляющее большинство компаний понимают это правильно. Но привлекательность бесполезна, если другие аспекты дизайна слабы.
В этом случае пользователям может быть неприятно или неудобно пользоваться продуктом в целом, и они перестанут это делать, даже если его функциональность превосходна. Все, что требуется, — это продукт с аналогичной функциональностью, но с более совершенным и более удобным дизайном.
Более того, пользователи могут даже не использовать большинство функций, если дизайн не сделан должным образом. Они не найдут этих функций и не поймут, как их использовать.
Достаточно вспомнить историю с выпуском первого iPhone, который не умел снимать видео, в отличие от конкурентов и многое другое. Но это совершенно не мешало его продажам. И это потому, что дизайн, от промышленного до графического, был потрясающим.
Дизайн является одним из основных столпов вашего продукта, который определяет его как внешне, так и внутренне. Это гораздо больше, чем стиль изображения, звука или текста. Это логика всего вашего продукта и она либо близка к совершенству, либо бесконечно далека от него.
Именно каркас корабля определяет его основные характеристики и несет знак на парусах. Поэтому дизайнеры должны обладать максимальной компетенцией, включающей знание лучших мировых практик, техническую экспертизу и эстетическое восприятие.
Разработчики
Без грамотных программистов ничего не получится.
Это одна из очевидных ловушек разработки программного обеспечения, но огромная и сложная. Да, проект может иметь большой коммерческий потенциал и отличное внутреннее и внешнее оформление, но его не будут использовать, если он будет работать некорректно.
Нет смысла перечислять, что может пойти не так в коде, если разработчик недостаточно компетентен. Это заслуживает отдельной статьи и очень большой.
Но в целом можно сказать, что не всякий работающий код является хорошим рабочим кодом. Любой подросток сегодня может создать свой веб-сайт или приложение, но как быстро это будет работать? Насколько стабильно это будет работать? Насколько безопасно он будет хранить данные? Все зависит от того, как именно написан код.
Компетентный разработчик знает все необходимое, от основ, таких как алгоритмы, структуры данных, шаблоны, архитектуры, до лучших мировых практик написания кода и многое другое. Не просто набор готовых к использованию технологий.
Это настоящие моряки на вашем корабле, повидавшие и бури, и тихие гавани. Которые выживали в океане разработки программного обеспечения как на огромных кораблях, так и на одиноких шлюпах.
Недостаточно хорошая атмосфера
Игнорирование прав человека
Игнорирование прав человека, как ни странно, по-прежнему является проблемой.
Мы не хотим затевать бурную дискуссию на эту тему, но стоит отметить, что разработка программного обеспечения по-прежнему является одной из тех сфер, где можно встретить сексизм и другие формы неуважения к правам человека и труду.
Некоторые компании до сих пор считают мужчин лучшими разработчиками, а женщин — хорошими дизайнерами. Но женщины не менее умны, а у мужчин не меньше хорошего вкуса. Весь цивилизованный мир понял, что эти взгляды, пол и прочие аспекты не имеют ничего общего с возможностями, склонностями, опытом и знаниями человека.
Также, чтобы уложиться в сроки и как можно быстрее решить непредвиденные трудности, некоторые компании пренебрегают правами людей в отношении графика работы и заставляют их работать сверхурочно. Но ошибки в постановке задач, установлении сроков и так далее, не должны оплачиваться теми, кто эти задачи выполняет.
Отсутствие вознаграждения
Отсутствие вознаграждения лишает стимула.
Человек делает что-то хорошо, только если у него есть положительный стимул делать это. А лучшая мотивация — это награда, в любой форме.
Это не значит, что человек плохой. Просто так работает человеческий мозг. Экономит энергию организма, если не видит способов ее пополнения.
То есть никто не будет вязать рыболовную сеть неделями, если она не принесет много рыбы. Многие люди гораздо больше ценят признание, одобрение и другие моральные поощрения, чем материальные блага.
Поэтому очень важно, чтобы сотрудники знали, что их усилия видны, а их результаты отмечены. Необходимо выразить признательность за инициативу и вовлеченность сотрудников. И будьте осторожны в поддержании стимулов, которые делают их работу продуктивной.
Недостаток обучения
Это очень распространенная ошибка разработки программного обеспечения, с которой не всегда могут справиться даже крупные компании.
Одна из самых распространенных причин перехода сотрудника в другую компанию, даже если у него отличная зарплата, должность и команда, — это когда он не видит своего будущего роста.
И если такой сотрудник уходит в другую компанию, это может создать огромную брешь, которую придется заполнять другими людьми. Все это может повлиять на процессы и потребовать неожиданных изменений в их организации.
Это как гребец, который научился грести одной рукой и не получил никакого другого инструмента. Но если гребец хочет выучить еще один инструмент, а вы не можете ему его дать, он перейдет на другой корабль.
Таким образом, помимо поощрений за хорошую работу и обучение, вам также необходимо предоставить им ресурсы, необходимые для обучения, и возможность продемонстрировать свои новые знания и навыки.
В заключение
Здесь мы поговорили о распространенных проблемах в процессе разработки программного обеспечения. Но их намного больше, и каждый мог бы занять целую отдельную статью. И, как вы могли заметить, нет первичных или вторичных. Здесь важно буквально все, и без должного внимания к каждому ничего толком не получится.
Как говорили великие, профессионализм проявляется в деталях. Внимание к каждому аспекту, каким бы незначительным он ни казался, отделяет успех от неудачи.
Поэтому желаем каждому кораблю в этом бескрайнем океане плыть навстречу открытиям, во всеоружии готовым ко всему!
Если у вас есть предложения или вопросы - будем рады ответить в комментариях.
Спасибо!
SIMPLicity
Прослезился читая...
Аминь!
PS Почему ни слова о стартапах и стартаперах? ....
... Да потому что удачливые стартапы и стартаперы напрочь ломают описанные наблюдения ...
Я совсем НЕ призываю ваять говнокод ради идеи, но именно так и появляются "единороги", которые видят нишу,- упираются рогом,- фигачат эджайл,- а потом продают(ся)... И им плевать на последующий взлёт или фэйл ихнего (бывшего) детища, ИМХО...
StupidMouse
встречал следующий подход в стартапе: ребята работали сознательно фокусируясь на максимальной скорости появления фич. очень быстро хотелось выйти на рынок и в случае успеха написать все заново, принимая во внимание косяки и узкие места первой версии, но до того момент был только девиз: бежать.