Как реорганизовать процесс разработки и увеличить её скорость, если нету документации, куча костылей и старый код?
====================================================================================================================

 Всем привет!  

5 лет назад создавал проект, на который был нанят один удаленно разработчик и дизайнер. Я выступал в роли ПМа.  

За это время проект сильно вырос и разросся и возникла потребность в увеличении скорости разработки, нужны ещё программисты.  
  

Но естественно никакой документации не велось, в коде разобраться сложно, первоначальная версия обросла тонной фич и костылей, фреймворк давно устарел, сам разработчик не хочет заморачиваться с рефакторингом/переписыванием, внедрением "best practice" и пр.  

Скорость разработки падает, костыли дают о себе знать, всё держится на одном человеке.  
  

Хочется привести всё в порядок: документация, тестирования, версионирование, CI и пр. красоту. Но компетенции таковые у меня отсутствуют и изучать возможности нету, деньги имеются.  
  

Нужна помощь. Как поступить?  
  

P.S. текущая идея. Делать хоть какую-то документацию по проекту и искать тимлида с опытом, кто возьмётся навести порядок. Или как вариант полностью на аутсорс отдать, но пугает отсутствие гибкости/оперативности. 

 Вариант только один. Искать нормальных разработчиков, делать НОРМАЛЬНУЮ документаци, налаживать процессы, автоматизировать все что должно быть автоматизировано, рефакторить все, что должно быть отрефакторено, выкидывать костыли и заменять их нормальными решениями. Можно постепенно, если можно, а не все сразу.   

Отдавать на аутсорс можно. Это довольно частая проблема, когда текущая команда не хочет изменений, или не в состоянии менять ничего. У нас приличное количество таких проектов. Отдать на аутсорс (можно и другой команде внутри) более мотивированной команде это один из выходов. 

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

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

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

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

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

1. фиксировать текущие требования к системе, то есть отвечать на вопрос как оно должно работать  

2. страховать от ошибок, которые могут возникать из-за костылей и неопытных программистов  

3. стабилизировать ветки разработчиков перед слиянием в мастер-бранч  
  

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

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

Иногда кол-во "фич" и костылей зашкаливает, а технологии устаревают настолько, что единственным адекватным решением является стать "фениксом".  

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

Конечно же этот способ работает только в случае подобном вашему. т.е. когда Вы обладаете достаточным объемом ресурсов (время и финансы) для найма профессионалов, способных на подобное действие. Максимально упростив текущую схему, перенеся её на новый функционал и обзаведшись хотя бы минимально необходимой документацией Вам будет легче сопровождать и модифицировать то, что Вы получите в итоге.  

Разумеется это ОЧЕНЬ сложный и рискованный шаг, но иногда сделать заново гораздо проще чем реанимировать умирающее.