4 всадника апокалипсиса: как выявить проблемы до того, как они возникнут в вашем программном проекте
Java-проект — основной продукт вашей компании? Работает уже более 10 лет? Вы зашли в тупик и изо всех сил пытаетесь найти выход? Чтобы заметить тревожные свидетельства, вам не нужно быть экспертом по разработке программного обеспечения. Вот четыре характеристики, которые помогут вам распознать проблемы с вашим продуктом:
1. Один из ваших ключевых разработчиков, много лет работавший над продуктом, думает об уходе из компании.
Вы вдруг понимаете, что если этот работник уйдет, многие знания будут потеряны. Что еще хуже, с этим разработчиком уходит большая часть будущего вашего продукта. В голове вы дышите в коричневый бумажный пакет.
Это произошло потому, что вы позволили этому человеку стать членом команды с единственной точкой отказа. Вместо того, чтобы обеспечить необходимую избыточность в вашей команде, вы оставили вещи без присмотра. Потому что не заботиться и удобно, и дешево. В результате, постоянно заставляя разработчиков работать на 110%, они выгорают. Затем они решают уйти. И верность здесь не при чем. Без обид, но даже самые преданные разработчики могут заболеть или умереть. Такова жизнь.
2. Вы не можете найти новых разработчиков среднего уровня.
Обычно эти ребята склонны выбирать проекты с возможностью их дальнейшего развития, чтобы стать сеньорами. Никому не нужна работа без возможности двигаться вперед. Старые библиотеки кода или языковые версии для них ядовиты. Если эти кандидаты постоянно отклоняют ваши предложения, дело может быть не в деньгах, плохом процессе найма или рабочей среде. Это из-за самого проекта.
3. На реализацию каждой маленькой функции уходят годы.
Любой проект может структурно умереть. Это не происходит в один внезапный момент, а скорее набирает скорость и разрушительную силу с течением времени. Одним из индикаторов этого является то, что любое изменение или расширение вызывает побочные эффекты. Чаще всего это происходит с монолитными структурами проектов, где логические разделы кода недостаточно разделены. Если расширения включают в себя большое количество изменений в коде, которые на самом деле не связаны между собой, то вы обычно сталкиваетесь с такой проблемой. Это только вопрос времени, когда обслуживание структуры займет больше времени, чем фактическая интеграция новых функций. Возможно, это уже происходит.
4. Ваши клиенты недовольны результатами.
Клиенты хотят, чтобы ваш продукт функционировал так, как им нужно для решения их проблем или пожеланий, а также чтобы он работал правильно, чтобы они могли достичь своих целей. Кроме того, они хотят, чтобы он не отставал от последних тенденций рынка и технического прогресса. Следовательно, клиенты требуют от вас современных обновлений и реализации новых функций. Ваш проект становится клиентоориентированным. И вещи выглядят черными. Почему это так? Компьютеры и серверы становятся все быстрее и быстрее, а ваше старое программное обеспечение тоже усложняется. Вместо рефакторинга таблиц запросов к базе данных люди склонны просто «вставлять» новые таблицы и запросы в существующую структуру. Следовательно, в процессе работы продукт получает только возрастающую сложность и фактор «ускорения до замедления».
Что делать?
Прежде всего, не играйте в игру с обвинением. Ваши действия не должны основываться на преступном поведении. Скорее всего, когда вы начинали, вы не могли позволить себе одновременно поддерживать удовлетворенность клиентов и их программный продукт в хорошем состоянии, так как это требовало времени и инвестиций. Обычно я также рекомендую стартапам быстро производить презентабельный продукт (минимально жизнеспособный продукт) вместо того, чтобы слишком концентрироваться на структуре. Структурно безупречный, но полуфабрикат не найдет покупателей. Проблема в том, что корректирующий рефакторинг часто забывают после того, как вмешался заказчик. Структура и внутренняя документация также не находят признания со стороны отдела разработки. Но теперь вы больше не стартап. Так что перестань вести себя как один. Ваша компания выросла, и теперь вам нужно принять меры.
Во-вторых, оставайтесь сосредоточенными и начинайте действовать. Есть стратегии, чтобы вернуть ваш проект в форму. Скажу честно, они не дешевые и не безболезненные. Тем не менее, более разумно нанять профессиональную помощь и получить доступных программистов с помощью услуг аутстаффинга, чем ждать, пока у вас не останется другого выбора, кроме как взять следующего лучшего аутсорсера или следующего лучшего разработчика, а затем положиться на толику удачи.
Поверьте, я знаю, о чем говорю. Я работаю в сфере IT уже 25 лет и видел неудачные проекты. В большинстве случаев руководство видело, что происходит. Однако они оставались пассивными и не предпринимали никаких мер по исправлению ситуации, так как не воспринимали ее всерьез или было удобнее игнорировать. И они заплатили за это.
Ваша задача здесь — вылечить существующие проблемы и не допустить создания новых. Если вы не знаете, как это сделать правильно, лучше обратитесь к специалистам. Но не позволяйте вещам стать критическими.
Удачи!
