А я предупреждал)

Тëмным, холодным, чуть горьковатым. Уууу...

Где тут sadness?)
Всё отлично: погода прекрасная, пиво вкусное, трава забористая, до работы 25 минут, можно хоть в тапочках в такую погоду ехать. xD

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

Ну Питер в целом радует в этом году. Питер - не Питер.

Рекомендую доехать до Local на Рыбинской

Или Бернард в Прага 5

Что-то в чате давно не было тем. Расскажу тогда про свой опыт. Как обычно про то, как не надо делать.

Читал недавно книжку, где была хорошая фраза:

"Сперва сделай, чтобы работало, затем сделай, чтобы работало правильно, в конце сделай так, чтобы работало быстро".

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

И вот если ваша команда на третьем шаге решила не менять техническое решение и пытаться реализовать всё на том не оптимальном стеке/техническом решении, которое было составлено изначально (из-за недостатка ресурсов, знаний стека и т.д.), то она нарывается на риски:
- сделать нерабочее решение
- сделать решение, которое сложно масштабировать
- сделать решение, которое будет медленно работать
- сделать решение, которое будет дорого сопровождать

Как оказалось, хуже может быть только тогда, когда вы ещё не закончили писать техническое решение, а разработка уже началась.
И это дополнительные риски:
- сделать решение, которое потом придётся частично переделывать (менять тесты, менять логику, менять структуру и т.д.)

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

И вот если ничего не получилось. Съезжайте с этого проекта/работы к чертям! xD
Т.к. со всеми проблемами этого проекта будут идти к вам. И внедрять его вам. И инциденты потом вам разгребать. И развивать систему тоже.
Ну а если съехать пока что не можете, то минимизируйте работу на проекте, выделите определённый объём времени в день на него, и сфокусируйтесь на личной жизни, учёбе, других делах. Примите за факт, что проект никчёмный и тратить на него нервы/лишнее время не стоит.

Почему?
Потому, что вместо того, чтобы выделить ресурсы и сделать всё как надо, команду обязали страдать. На ваших нервах/усилиях решили сэкономить.
Ну а вы на работу не страдать пришли, а работать. Так что главное не делайте это своей проблемой.

Наверное я кэп, но всёж.

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

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

Это про документацию или про требования? Если про документацию, то пока нет понимания зачем и кому это надо, она не будет работать никак, не то что правильно или быстро. Если информация не подготовлена специально под аудиторию, её считай, что нет. Хуже, чем нет. Она лежит, она устаревает, люди приходят потом, пытаются понять что это было, путаются, плюются.

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

Документация в современном ИТ - это в первую очередь коммуникация, а потом уже хранение знаний. Коммуникация не может быть рабочей, если она неправильная.

Про то, чем вредно описание реализации в требованиях в 14-м году говорила на ЛАФ https://vimeo.com/100883572

У меня обычно проблема в том, что все бразды управления архитектурой забираются. А мне, как к системному аналитику, часто приходят с вопросами "сфигали?".
Архитектором может стать и начальник финансового отдела, если слишком рьяно будет влиять на проект. Это конечно глумно, надо откинуть риски кому надо, напялить ему шляпу архитектора и наблюдать за шоу.
В моём кейса архитектором стал человек, которому горящие сроки важнее качественной архитектуры. С вытекающими.

Ну вот и взял шляру мул, что решил тащить)

Так он потащит к обрыву. Суть же в том, чтобы решение было качественным, а не в том, чтобы через квартал вся команда горела и хотела соскочить с проекта?
У меня часто проблема, что нет ответственных, шляпу берёт кто попало и работа с решением становится похожим на гонки со сроками в рамках закостенелого стека без вариантов выбора.

Согласен, требования вообще надо отрезать от реализации. Сегодня одна реализация, завтра другая.
Я больше про системную аналитику, когда ты занимаешься описанием грядущей реализации.

Я недавно освоил прямо противоположный подход - непрерывный допил текущего решения, который заведомо должен быть изменён при первой возможности. "Непрерывное улучшение")

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