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

• Заказчик, его адекватность, стремления и реальная ценность проекта для него
• Архитектура решения, платформа и всё такое
• Качество проектных результатов

Как обычно, начинаем с самого главного, с людей.

Заказчик

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

На основе своего болезненного опыта лично я выработал (обманчиво) простой опросник, по которому бизнес-заказчика обязательно надо оценить:

• Адекватность
• Мотивы
• Что ему нужно от проекта

Наверное, адекватность – одна из самых сложных тем. Поскольку здесь я не профессионал (т.е. не психолог или логопед), то вынужден ориентироваться по косвенным признакам:

• Предсказуемое поведение; если общение длится какое-то время, можно смоделировать похожие ситуации. Так вот, если реакция человека похожа в похожих ситуациях, или он сам объясняет вам, почему его реакция отличается – ставим плюсик. Если же реакция человека различается, но он аргументирует это не логически, а погодой и другими внешними обстоятельствами – у вас проблема. Как минимум, у человека проблемы с саморегуляцией своего эмоционального состояния. В худшем случае – сбои в логических цепях (хотя вот тут я не уверен, что хуже).
• Мотивы: зачем он ходит на работу? У него есть хоть что-то, что ему нравится в самой содержательной части работы, или его функция оптимизации делать минимум, получать максимум? Бизнес-заказчиками редко ставят людей, которые представляют свою работу как греблю на галере. В идеальном случае у него есть какие-то профессиональные ценности и личные устремления в части развития и достижений. Поговорите с ним об этом: если вы нащупаете нужную тему, то обретёте надёжного долгосрочного союзника. Если этого нет, и вопрос только в деньгах, с этим работать тоже можно, если в стремлении работать осталась порядочность и добросовестность. С чем нельзя работать – так это с безразличием. Что у меня получалось делать в случае с безразличием, так это наступать на больную мозоль и потом вести переговоры в духе "давайте подумаем, что вы сделаете для того, чтобы я с этой мозоли ушёл". Не очень приятно, но работает.
• Ценность проекта для него. И здесь не нужно жалеть времени для обсуждения, все передовые методики (взять тот же JTBD) строятся на фундаменте ценности. Это должно быть устранение понятной боли либо добавление возможности, которая нужна для чего-то очень конкретного (выхода на новый рынок, получения конкурентного преимущества). Но это ценность для бизнеса, а как цели конкретного человека связаны с целями бизнеса? Может быть, что никак. Может быть, от него отстанут. Может быть, для его мотивации достаточно, если он делает что-то важное для компании, в которой работает. Вот в последнем случае я бы не останавливался, а продолжал обсуждать. По опыту требуется от трёх до пяти встреч, чтобы выровняться по тому, в чём результаты проекта для вас и предполагаемая ценность для бизнеса, и то же самое + ценность для бизнес-заказчика лично. И тут рассмотрим самый плохой вариант: отказ, отсутствие интереса к этому обсуждению – это очень, очень плохой признак. Смотри "безразличие" в пункте выше. Но тут лекарство другое: выходить на уровень акционеров и просить сменить бизнес-заказчика, это вполне достаточная и необходимая причина.

Архитектура решения и платформа

Если в вашем проекте существенным результатом является разработка или внедрение ИТ-решения, то нелишним будет честно собрать ответы на такие вопросы:

• На достаточно ли современной платформе строится решение?
• Велик ли объём технического долга?
• Достаточно ли современные решения в части архитектуры принимаются в рамках проекта?

Тут всё просто, достаточно поговорить с разработчиками. Они, как правило, топят за наиболее продвинутые решения, и у них болит душа от костылей и legacy, то есть кривых унаследованных решений, а также от критического объёма технического долга. Наоборот, они будут рады встретить человека, которому наконец можно высказаться.

В части платформы и её современности есть несколько подвопросов для оценки:

• Сколько лет разрабатывается решение? Лет = баллов, поскольку всё развивается очень динамично (больше 10 уже не важно).
• Остались ли в команде разработчики, которые начинали писать это решение?
• Платформа входит в мейнстрим или это штука "для знатоков? Одно дело, если веб-решение строится на python / php / java, и другое, например, когда scala, разработчиков найти существенно труднее.

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

Качество проектных результатов

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

• Соблюдается ли принцип "сверху-вниз": эпики и задачи или видение модулей и их взаимодействия на верхнем уровне. В целом возможность переключения между разными уровнями абстракции, это одна из разновидностей признака "а была ли здесь мысль?" Если документация похожа на лоскутное одеяло, части которого противоречат друг другу и слабо складываются в общую картину, всё уже плохо. Ну и лечение здесь: сделать описание на верхнем уровне и обновить документацию.
• Выровнен ли словарь как в проектной документации, так и в том, как общается проектная команда? Идеальный вариант, когда есть отдельный (обновляемый) словарь, особенно с расшифровкой аббревиатур. А вот нерасшифрованный сленг будет постоянно приводить к путанице.
• Есть ли следы процессного подхода? Качественный текстовый документ, но с процессным подходом, будет лучше хаоса из картинок в Miro или Figma. В двух словах про процессный подход объяснить не смогу, зато есть отдельная статья.

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

И что дальше

А дальше предстоит ответить самому себе на несколько вопросов:

• Хочу ли я с этим связываться?
• Надо ли что-то менять (например, переписать документацию, сменить платформу)?
• Насколько реальны с учётом новой информации параметры проекта: сроки, объём, бюджет?

В последний раз в этой статье встряну с личным опытом, но вы уже знаете ответ: конечно надо менять и всё перепланировать. Если вы целитесь быть руководителем проекта, а не фигурой сбоку, про которую скажут: "собака лает, караван идёт". (С) Зато всё плохое, что произойдёт дальше, свалят на вас, будьте уверены. И аргумент "я же поднимал этот вопрос" не подойдёт. Поднимать недостаточно, надо делать.