💵 Так как же экономить на этапе оценки требований?
Люся Сидорова хотела выйти замуж по расчёту... Но не смогла. Она гуманитарий.
Так уж сложилось на постсоветском пространстве, что большую часть требований пишут Product Manager, Business Analyst или т.п. персоны, а технарей к составлению требований допускают редко. Технарям достается роль в оценке хотелок. При этом почти всегда сперва пишутся требования и логика работы приложения, а затем его передают на оценку технарям.
Напомню про график из предыдущей публикации. Перетраты на исправлениях до 5 раз возникает когда технари и постановщики задачи начинают футболят в друг друга требованиями и оценками.
💊 Самая эффективная рекомендация! Можете ее показать своим менеджерам. Обьясняйте технарям всю задумку и идеи стоящие за этой задачей. Почти всегда инженер, который не просто делает работу, но и понимает зачем ее делает, предложит как срезать острые углы и может предложить слегка видоизменить требования чтобы сэкономить на этапе разработки.
После прохождения этого этапа в отношениях, можно переходить к более высокоуровневым вещам. Например, обучать базовым инженерным практикам нетехнических постановщиков.
В моем опыте были объяснения:
- как работает протокол HTTP, WebSocket
- как ведет себя браузер после запроса загрузки страницы и до закрытия табы
- что такое сессия пользователя
- как происходит балансировка нагрузки и почему два запроса подряд на разных серверах могут выполняться
- что за магия с cookies и local storage
- и многое друго...
❓Почему❓ Вот хочет реализовать постановщик логику работы чатов на WebSocket. В его мире “ДО” нажатие кнопки “отправить сообщение” было неразрывно связано с тем фактом, что сервер получил сообщение в риалтайме и обработал его. Когда объясняешь, что банально в момент отправки соединение может быть не установлено, может быть в процессе реконнекта и тп, то после этого человек уже формирует требования с учетом разных состояний соединения! Когда объясняешь, что у могут быть синхронные и асинхронные запросы, а пока ответ летел клиенту с сервера, то состояние на сервере могло уже поменяться, то качество проработки edge cases и fail-сценариев в требованиях вырастает в разы. Это и создает экономию на этапе написания требований.
Итого, на этом этапе рекомендую составить список “нюансов” из доменной области, задокументировать их и обьяснить детали. Также неплохо иметь чекисты перед выдачей требований. “Учтены ли таймауты в ответах”, “Учтены ли ошибки и проработана ли реакция на них“ и подобные чеклисты будут верными помощниками.
@noTieInIT
Люся Сидорова хотела выйти замуж по расчёту... Но не смогла. Она гуманитарий.
Так уж сложилось на постсоветском пространстве, что большую часть требований пишут Product Manager, Business Analyst или т.п. персоны, а технарей к составлению требований допускают редко. Технарям достается роль в оценке хотелок. При этом почти всегда сперва пишутся требования и логика работы приложения, а затем его передают на оценку технарям.
Напомню про график из предыдущей публикации. Перетраты на исправлениях до 5 раз возникает когда технари и постановщики задачи начинают футболят в друг друга требованиями и оценками.
💊 Самая эффективная рекомендация! Можете ее показать своим менеджерам. Обьясняйте технарям всю задумку и идеи стоящие за этой задачей. Почти всегда инженер, который не просто делает работу, но и понимает зачем ее делает, предложит как срезать острые углы и может предложить слегка видоизменить требования чтобы сэкономить на этапе разработки.
После прохождения этого этапа в отношениях, можно переходить к более высокоуровневым вещам. Например, обучать базовым инженерным практикам нетехнических постановщиков.
В моем опыте были объяснения:
- как работает протокол HTTP, WebSocket
- как ведет себя браузер после запроса загрузки страницы и до закрытия табы
- что такое сессия пользователя
- как происходит балансировка нагрузки и почему два запроса подряд на разных серверах могут выполняться
- что за магия с cookies и local storage
- и многое друго...
❓Почему❓ Вот хочет реализовать постановщик логику работы чатов на WebSocket. В его мире “ДО” нажатие кнопки “отправить сообщение” было неразрывно связано с тем фактом, что сервер получил сообщение в риалтайме и обработал его. Когда объясняешь, что банально в момент отправки соединение может быть не установлено, может быть в процессе реконнекта и тп, то после этого человек уже формирует требования с учетом разных состояний соединения! Когда объясняешь, что у могут быть синхронные и асинхронные запросы, а пока ответ летел клиенту с сервера, то состояние на сервере могло уже поменяться, то качество проработки edge cases и fail-сценариев в требованиях вырастает в разы. Это и создает экономию на этапе написания требований.
Итого, на этом этапе рекомендую составить список “нюансов” из доменной области, задокументировать их и обьяснить детали. Также неплохо иметь чекисты перед выдачей требований. “Учтены ли таймауты в ответах”, “Учтены ли ошибки и проработана ли реакция на них“ и подобные чеклисты будут верными помощниками.
@noTieInIT