Практически все, кто работает в области ИТ, хотя бы раз сталкивались с понятием «технического долга» – тем, что последствия решений «сделать быстро, но не очень хорошо» имеют свойство накапливаться, и потом могут вылиться в куда большие затраты времени, чем если бы мы изначально делали все нормально. Но сейчас речь о менее популярном термине, об «управленческом долге». Сталкивались?
Управленческий долг – это примерно то же самое, что и технический долг в разработке. Вы принимаете решение в проекте в краткосрочной перспективе и потом живете с его последствиями или в какой-то момент начинаете их разгребать, возможно, тратя больше времени или денег, чем сэкономили. Примером может служить все что угодно – скажем, вы решили не оформлять аналитику командировку в офис в Конго (долго, дорого, прививку от малярии и желтой лихорадки надо делать), проговорили все удаленно с будущими пользователями, они все ваше ТЗ согласовали (тем более, что по-английски не очень читают), вы сделали систему и внезапно выяснили, что это вообще не то. И вот аналитик уже летит в Конго, выяснять на месте, а как должно быть «то».
Или вы поленились или предположили, что заставлять всех вести календарь доступности на работе (отпуска, вахты и проч.) – это лишнее в этом небольшом проекте. И теперь тратите гораздо больше времени на переписку в аутлуке и скайпе на тему «кто когда идет в отпуск» и синхронизацию с командой (и все равно периодически получаете проблему), а календарь в середине проекта – это как-то глупо уже.
Или как описано в кейсе с аналитиком-РМом – держите человека, т.к. боитесь, что поедут сроки, и в итоге они едут еще больше, т.к. человек раз за разом заваливает работу.
К моему любимому ремонту, чтобы уж совсем очевидно было – хорошим примером управленческого долга может быть случай, когда ваш подрядчик, делающий вам, скажем, электрику в квартире, проявил инициативу и сгонял на своей машине купить 2 недостающие подрозетника для гипсокартона по 30 рублей, чтобы работы не встали. При этом спросил у вас разрешения (мол, купить материалы, чтобы не тормозить работу) и оплатите ли вы бензин. Вы, замотанные этими своими ИТ-проектами на работе, не стали вникать, покивали и согласились, мол, да, молодец, работа стоять не должна, покупай все, что нужно. При этом у вас не нашлось времени проговорить детально тот факт, что согласуете вы только одну поездку и покупку только подрозетников. Товарищ услышал вас по-своему, и за те три недели, пока вы не находили времени приехать проверить работы, не согласовывая с вами, съездил на рынок еще раз 8, и теперь притащил вам счет на бензин на 4500 рублей (9 поездок по 500 рублей) и счет на дополнительные материалы, которые вы только вчера купили сами и сегодня ему привезли, т.к. думали, что их нет. А еще на самом деле купить это все он вполне мог за 1-2 поездки, но вы же согласовали все, деньги ваши, почему бы не покататься до рынка и развеяться?
В итоге вы сэкономили 15 минут на обсуждении, а потом час обсуждали, как так вышло и еще полчаса договаривались о том, что так делать не надо. Потеряли больше 5000 рублей, да еще и электрика демотивировали, он же хотел как лучше и теперь считает вас неблагодарной сволочью.
Мораль проста и банально – пробуйте просчитывать результаты «упрощения» процессов проектного управления на пару шагов вперед и, возможно, отводить больше времени на них. Чаще всего это окупается, хотя, конечно, каждый случай индивидуален. И ведите «логи» таких решений, чтобы потом понять, во что это вылилось, и извлечь уроки. Мы вот у себя недавно включили такой функционал в нашу системку управления проектами – все подобные решения логируются, их можно отследить и проанализировать. Через годик посмотрим на результаты.
Добавить комментарий