IT-беседка

Где граница, когда разработка может менять задачи бизнеса, а когда нет?

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

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

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

Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,

Куда точно не стоит лезть?
Чего точно не стоит делать без участия бизнеса, так это менять сроки и состав заранее согласованных релизов и запусков. Бизнес должен однозначно решать, какой функционал должен стать доступен пользователю в каком составе. Иногда может казаться, что лучше сделать пол задачи и выкатить, чем не успеть все целиком, но для бизнеса половина задачи может быть либо юридически недопустимой, либо ломать пиар-компанию, которую месяц готовили и обещали совсем другое. Поэтому во всем, что касается изменения сроков и состава релизов, обязательно нужно консультироваться с бизнес-заказчиком и решать все изменения совместно.

Заведите правила
В идеале, вам с бизнесом нужно совместно составить четкие правила, что входит в их компетенцию, а что в вашу. Тогда вы просто работаете по этим правилам и все будут довольны. Конечно же каждую мелочь в правилах не опишешь, поэтому основные принципы стоит понимать.

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

Александра Шаламова
#agile_который_работает

419 views06:59