Про гипотезы.
До IT я работал геологом в нефтянке в ГТИ геологом и технологом по бурению (первое образование у меня средне-спциальное геологическое). И вот что-то происходит во врем бурения. И ты начинаешь прикидывать что могло произойти и проверять, совпадает ли произошедшее со ожиданим или нет. Так работали все вокруг, и никого это не удивляло. Позже, когда я перешел в IT для меня оценка задач не была проблемой. Я ведь построил гипотезу как будет работать фича, согласовал с бизнесом или уточнил какие-то моменты что нужно будет сделать, а что не обязательно, и перед реализацией уже имел поинмание что нужно будет поменять. И весь этот «плач Ярославны» всегда проходил мимо меня, ну да, время может плавать, особеное если всплывут детали, но если предупредить бизнес, где детали могу всплыть, всегда можно передоговориться или чтобы бизнес был готов.
Что интересно, я согласен с доводами, что разработка это не механическая работа по штамповке деталей штук в минуту, но не согласен, что она творческая. Она исследовательская, но у нас уже есть механизм того, как работают ученые, они не творят. Они строят гипотезы, затем придумывают эксперемент, и проводят его. Все, тут нет особо творчества (хотя что можно считать творчеством или искусством это вообще философский вопрос)
Сейчас, как тимлид, особенно это проявляется в эпоху ИИ, я стал сталкиваться с тем, что для людей проблематично оценить задачу. Я пришел к выводу что разработчики часто не строят гепотизы, или не осознают что они строят гипотезы, просто у них есть в голове что-то не четкое. Поделюсь как быть с оценкой в этой ситуации.
• Вы строете в голове т.н. happy path, как должна успешно отработать фича по шагам.
• После этого, вы начинаете думать что на каждом шаге может пойти не так (чем больше у вас опыт, тем проще это делать, тут и со стороны безопасности проблемы смотрите и со стороны производительности и со стороны ux и т.д.)
• Если видите недостаток информации (например будет ли пользователь видеть loader, пока идет обработка get запроса), противоречеие (заказ не может быть одновременно и не оплачен и не в корзине - значит нужно промежуточное состоние ожидание оплаты, как это видет пользователь?) или необходимость что-то внедрить (например rate limit для попыток авторизации), то озвучиваете это бизнесу/тимлиду, предлагаете свой вариант и приходите к компромису
• Теперь у вас есть что-то типо дерева фичи (особенно если есть ситуации, когда нужно вернуть сообщение пользователю что фича не отработала)
• Теперь выясняяете как это все посадить на существуюущую базу данных.
• И в конце вы продумываете где в коде вы будете что менять (даже если нейронка, вы понимаете +- какие фичи затронет и в каких слоях будет работа)
И все, тут уже можно прикинуть, сколько вашу гипотезу реализовывать.
Ах да, не играйте в игру «я тебе все равно докажу что твои сроки не реалистичны», предлагайте либо как разрезать фичу на несколько задач и распаралелить или предлагайте от чего отказаться.
До IT я работал геологом в нефтянке в ГТИ геологом и технологом по бурению (первое образование у меня средне-спциальное геологическое). И вот что-то происходит во врем бурения. И ты начинаешь прикидывать что могло произойти и проверять, совпадает ли произошедшее со ожиданим или нет. Так работали все вокруг, и никого это не удивляло. Позже, когда я перешел в IT для меня оценка задач не была проблемой. Я ведь построил гипотезу как будет работать фича, согласовал с бизнесом или уточнил какие-то моменты что нужно будет сделать, а что не обязательно, и перед реализацией уже имел поинмание что нужно будет поменять. И весь этот «плач Ярославны» всегда проходил мимо меня, ну да, время может плавать, особеное если всплывут детали, но если предупредить бизнес, где детали могу всплыть, всегда можно передоговориться или чтобы бизнес был готов.
Что интересно, я согласен с доводами, что разработка это не механическая работа по штамповке деталей штук в минуту, но не согласен, что она творческая. Она исследовательская, но у нас уже есть механизм того, как работают ученые, они не творят. Они строят гипотезы, затем придумывают эксперемент, и проводят его. Все, тут нет особо творчества (хотя что можно считать творчеством или искусством это вообще философский вопрос)
Сейчас, как тимлид, особенно это проявляется в эпоху ИИ, я стал сталкиваться с тем, что для людей проблематично оценить задачу. Я пришел к выводу что разработчики часто не строят гепотизы, или не осознают что они строят гипотезы, просто у них есть в голове что-то не четкое. Поделюсь как быть с оценкой в этой ситуации.
• Вы строете в голове т.н. happy path, как должна успешно отработать фича по шагам.
• После этого, вы начинаете думать что на каждом шаге может пойти не так (чем больше у вас опыт, тем проще это делать, тут и со стороны безопасности проблемы смотрите и со стороны производительности и со стороны ux и т.д.)
• Если видите недостаток информации (например будет ли пользователь видеть loader, пока идет обработка get запроса), противоречеие (заказ не может быть одновременно и не оплачен и не в корзине - значит нужно промежуточное состоние ожидание оплаты, как это видет пользователь?) или необходимость что-то внедрить (например rate limit для попыток авторизации), то озвучиваете это бизнесу/тимлиду, предлагаете свой вариант и приходите к компромису
• Теперь у вас есть что-то типо дерева фичи (особенно если есть ситуации, когда нужно вернуть сообщение пользователю что фича не отработала)
• Теперь выясняяете как это все посадить на существуюущую базу данных.
• И в конце вы продумываете где в коде вы будете что менять (даже если нейронка, вы понимаете +- какие фичи затронет и в каких слоях будет работа)
И все, тут уже можно прикинуть, сколько вашу гипотезу реализовывать.
Ах да, не играйте в игру «я тебе все равно докажу что твои сроки не реалистичны», предлагайте либо как разрезать фичу на несколько задач и распаралелить или предлагайте от чего отказаться.