Рассмотрю несколько вариантов развития событий, основываясь на своем опыте и опыте коллег из других компаний.
Сразу стоит отметить, что у меня нет для вас релевантного опыта проектов, на которых очень много людей (30-50-100+) работает. Есть только опыт для команд из 5-10-15-20 человек.
Вариант №1
Программист, получивший задание, смиряется с рядом надежд (они же риски):
– ТЗ написано внятно, корректно, без противоречий.
– Заказчик точно уверен, что ему это вообще нужно и именно так, как он просит.
– ПМ/тимлид/старший товарищ эту задачу обдумали, обсудили, разжевали и только после этого передали ему.
Ну и всё, программист особо не заморачивается, делает задачу в надежде, что риски не стрельнут. Иначе ему придется или что-то переделывать (порой много чего) или вообще его поделка не увидит свет.
Как показывает практика, эти риски стреляют довольно часто в силу разных причин: плохо договорились, не подумали, поговорили на разных языках (образно), каждый понадеялся на другого и т.д.
Вариант №2
Программист, получивший задание, старается устранить эти риски. Лично я делаю так и рекомендую так же поступать коллегам на всех этапах работы, начиная от начального этапа сбора требований.
Следует понимать, что заказчик порой сам не уверен, что ему нужно конкретно вот так вот сделать. Однако приходит он к вам с уверенным лицом. Вам надо помочь ему понять, действительно ли ему это надо, действительно ли вот так, а не иначе, что он хочет от этого получить и т.д. Помогите ему разобраться, помогите доработать ТЗ, помогите себе и вашим коллегам обрести уверенность в том, что эту задачу не надо будет переделывать или отменять.
Да, вы потратите несколько больше времени на этапе выявления требований и проектирования, но в дальнейшем сэкономите время и нервы, плюс сможете получать более предсказуемый и прогнозируемый результат своей работы.
Нихотю
Вы справедливо можете сказать: “А что это я буду с этим разбираться? Вон ПМ есть, тимлид, лид. Пусть они и разбираются. Мне деньги платят, чтобы я код писал». Ну да, всё так и есть. Вы совершенно правы, и, конечно, никто вас принудить к этому не может, если вы не хотите. Но помните, что потому тимлид/лид и заняли свои позиции, что не брезговали погружаться не только в код, но и в бизнес часть проекта. Желаю вам удачи на очередных торгах за повышение зарплаты:)
Итог
Важно и нужно анализировать задачи, начиная с самых ранних этапов. Не надо быть наивным в надежде на то, что ничего не случится, и до вас все подумали хорошо, потому что они специалисты (не факт).
Тот, кто этим займется – будет ощутимо ценнее для бизнеса и команды, чем тот “с чьей стороны пули вылетели”. Успехов!
