Неужели настоящие программисты кончаются?
Миллениалы и вайб в it - это теперь норма, а не прикольный мем?
Для ЛЛ: Нужно инструкции в ТЗ делать, как в детсаде: пяточка, носочек, топ, топ, топ, иначе у программистов код не пишется. Этих "программистов" можно заменять ИИ. Факт?
Текст для it-шников, другие и не поймут.
Я был и прогером, и тимлидом, и пм, и аналитиком за 23 года карьеры. Беру подработки на написание ТЗ как технический писатель+.
Опишу только последний заказ, внутри всё, что было и в прошлых недавних.
Мне дали swagger внешней системы БЕЗ доступа, чисто json. Одну кривую недоработанную bpmn. Нужно за 3 недели описать основные структуры, 1-й этап.
1. Представил основные объекты, CRUD (и что с ним делать), бизнес-логику, всё по уму: dto, действия по пунктам, все поля. Сказали - мало подробностей, сделал подробное описание.
2. Бизнес-модели, в том числе и картинками, схемами, для более сложных случаев. Сказали - малоинформативно, добавил "ёжиков и зайчиков", как для детсада, без иконок не понимают.
3. Негативные сценарии, ретраи - мало данных. Послал лесом (в голове), прописал по максимуму, но не по каждому полю.
4. Моя инициатива: SQL-скрипт для полного создания БД со всеми связями (кто бы мне когда такое дал!)
Итого: 230 страниц (без sql) ТЗ для 45 объектов, из которых 35 - тупые справочники (1 этап же!)
А теперь жалобы на ТЗ!!!
1. Нужно расписать все валидации и ошибки
- Реально, гайз?
- Вот пример!
Шаг 1. Проверить входные параметры: Если поле name = null то переход к шагу 2. Иначе исключение.
Исключение 1: не заполнено поле name. Вернуть ответ с http-кодом = 400 Bad request в
вызывающую систему и заполнить выходные
параметры:
errorMessage = Выбрать значение text из
таблицы messages, где:
id = catalog.object.bad_request
language = Значению lang из
входных параметров либо 'RU'
если lang пустой
timestamp = Текущая метка времени
Шаг 2. Проверить входные параметры: Если поле name = String.Empty то переход к шагу 3. Иначе исключение.
Исключение 2: Поле name пустое. Вернуть ответ с http-кодом = 400 Bad request в
вызывающую систему и заполнить выходные
параметры:
errorMessage = Выбрать значение text из
таблицы messages, где:
id = catalog.object.empty_request
language = Значению lang из
входных параметров либо 'RU'
если lang пустой
timestamp = Текущая метка времени
- И вот эту херню для каждого поля каждого объекта требуют!!! Серьёзно??? Прочитать описание сущности, где указано nullable, unique, sample, description нельзя??? Там даже мозг включать не нужно, да ИИ если нужно распишет. Но it прислали пример именно в такой форме 0_0. Послал лесом, каждое поле не расписывал, иначе ТЗ за 1000 страниц ушло бы.
Не, реально? 230 страниц на 35 crud + 10 чуть сложнее, + ровно 4 запроса к другим системам (ну и 16 запросов справочников и 5 без интеграции) и всё по теме - этого мало? Нужно 1000+ страниц? И это при готовом скрипте создания БД? Когда ну всё-всё-всё по логике прописано, кроме микроменеджмента...
Оказалось: мало.
Вот что с меня требуют сейчас НЕ по технической части:
1. Жизненные циклы всех сущностей с инфографикой. - Да, уже всё есть, простые справочники, CRUD, прописаны post/get/put с dto и все действия по пунктам, sql БД даже есть со связями. Но! Нипонятнаааа. Дай картинкую и схемую и всё всё на случай вдруг что. И bpmn нарисуй - наш отдел аналитики другим занят.
2. Статусная модель, Правила переходов - Тупые, уже всё есть. И какие статусы для справочников? Явно вопросы ИИ писал.
3. Сценарии из фронта, партнерский/... сценарий. - И фронт вам расписать??? И UI/UX?
До черта, что не входит в задачу на этот этап разработки. Но кто ж читает?
Ну да это всё фигня, дальше тех. требования от it-шников, бывших коллег так сказать:
● Структурированное представление ключевых концепций - эм, для основы, для справочников, при приналичии скрипта постороения БД? И у меня спрашиваете, а не ваших аналитиков???
● нет bounded contexts
● нет API-границ
● нет схемы интеграции
● Используется ли Saga? Outbox? Retry policy?
● Используется ли хеш БД типа Reddis?
● Каким ПО формируются очереди?
● Как предотвращаем дубли при ретраях?
● Какой дизайн для “at-least-once” вызовов?
● Как обрабатываем callback/webhook? - всё описано, но ИИ, видимо, не дочитал.
и ещё миллион вопросов по "Выбор паттернов проектирования и программирования, решений, инструментов/сервисов".
ИТОГ: Может, сейчас так принято? Может, я устарел? В ТЗ сейчас нужно расписывать, как жопу подтирать по шагам? Ну тогда нафига программисты, скорми такое ИИ - он весь код и напишет на нужном языке. Одна беда - технический писатель вдруг должен быть всеми: от аналитика до техлида, всё до мелочей расписать, а может и скрипт подогнать, чтобы всё по клику в k8s развернулось.
Объясните, пожалуйста, это сейчас норма?
А я поясню, почему это "сейчас норма".
Они не технического писателя наняли, она наняли спеца, который разгребёт бардак в их собственных видениях и пониманиях системы, её функционирования, сути и ограничений. Можете просто поверить, ни один из представителей Ваших контрагентов не знает и не представляет до конца ни свой отдельный кусочек реализации кода/интерфейса/железки, ни в целом систему. Мало того, представления отдельных личностей настолько разнятся, что противоречат не просто друг другу, но и порой намеренно да тщательно скрыты от других.
Итогом является разработка системы, в которой:
1) нигде нет полного, целостного и непротиворечивого описания хотелок;
2) куча народу не может увидеть потенциальных проблем в конкретных местах ровно до момента непосредственно реализации;
3) каждый, имея собственный багаж знаний и "ну это всем известно", не представляет как именно в процессе кодинга ему взаимодействовать с сопряжёнными спецами, что требовать, предоставлять и проверять;
4) смена исполнителей и подключение новых непрерывно порождает внутренние недокументированные легаси куски, которые просто невозможно в разумные сроки проанализировать без изначального понимания требований к функционалу конкретного модуля;
5) нет возможности убедиться в полноте проводимых тестов и их адекватности для релиза...
и т.д.
На самом деле, высказывая свою критику в приведённом ключе, Вы попадаете в ту же ловушку и делаете её же для остальных разработчиков. Но это из-за непонимания конретной роли техписа как Вами, так и заказчиками: в Вашем случае требуют то, что они сами должны делать на этапе после ТЗ - программную документацию. Полностью, по ЕСПД, с утверждением перечня разрабатываемых документов и согласованием самих документов с заказчиками. Сей кейс может быть более-менее обоснован только в случае работы на оборонку: там ТЗ может содержать вообще всё, что нужно сделать и будет именно тем букварём, по которому пойдут все проверки вообще всего, а не только самого продукта.
Что они хотят получить и почему:
1) Максимально чёткое и подробное описание требований к каждой функции, каждому процессу и кнопке, которые уже есть или будут реализованы/заимствованы. Без этого нельзя проверить правильность навороченного.
2) Полную и достаточную картину будущей системы, без которой они не смогут сформировать у себя её представление, проверить структуру, взаимодействие и процессы, выявить узкие моменты и устранить их.
3) Описание для тупых, достаточно простыми и понятными словами, которое будет одинаково воспринято всеми задействованными лицами, независимо от их квалификации. Да, вполне вероятен сценарий, при котором конкретный тест конкретного модуля будет делать племяш начальника отдела конструкторов, которого наняли в качестве программиста и дали задачу на отъебись, лишь бы чем был занят. И он не знает что такое справочники. Вы не докажете полноту своих усилий фразами "это все знают" или "компетенция программиста подразумевает", если на Вас захотят повесить собак.
Что делать в Вашем случае.
1) Сделать то, о чём договаривались изначально. В рамках перечня работ или начальных требований.
2) При получении задания на уточнение чего-либо сформулировать новую работу в рамках старой, обсудить и выставить новые сроки, оплату, затребовать полномочия на взаимодействие с сопряжёнными спецами (кто вообще должен давать требования к диаграммам?)
3) Требовать исходные данные, отмечать в собственной дорожной карте кто когда и что предоставил или не предоставил.
4) Следить за любыми потенциальными затыками (с получением начальных данных/ утверждением или согласованием промежуточных результатов/уточнением состояния стратегической линии в целом). При любых проблемах не сидеть на жопе ровно, а стучать по голове причастным или их руководителям.
Нахера так сложно и, главное, зачем? Затем, что без всего этого можно очень быстро разработать нужный продукт, который, если повезёт, прослужит всего ничего и будет выкинут на помойку. Потому что разобраться в его исходниках, структуре, процессах и идеях будет сложнее, дольше и дороже, чем сделать вообще с нуля новый такой же, но с одной маленькой новой свистоперделкой. И если для крайне простых продуктов это действительно канает, то для чего-то более-менее объёмного только за счёт постоянных доделок и костылей система устареет раньше, чем вылезет в свет.
Всё, что надо сделать - запиши. Всё что сделал - тоже запиши.