Несколько принципов из менеджмента, которые вполне пригодятся программисту при решений проектных вопросов

Дисклеймер для супер-пупер проект-менеджеров и прочих заклинателей сферы управления IT-проектами.

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

Многие разработчики в своей карьере так или иначе сталкиваются с нередко ставящими в тупик и заставляющими понервничать вопросами, наподобие:

• оценка стоимости работ;
• выбор технологий реализации (язык программирования, база данных, используемые библиотеки и фреймворки, архитектуры и пр.);
• оценка сроков и пр.

Когда вначале за вас всем этим занимается какой-то сторонний человек, вы не паритесь и тупо кодите (в стиле "не шалю, никого не трогаю, починяю примус..." из многим известного романа "Мастер и Маргарита"), но потом всеравно наступает момент, когда уже вам нужно будет принимать какие-то проектные решения. Конечно стараясь не оплошать, вы будете нервничать, наивно пытаться обсчитывать все возможные нюансы и риски, занижать сроки, переоценивая свои возможности или боясь показать себя недостаточно профессионально, а потом, как обычно неожиданно, проснется закон подлости и все пойдет совсем не так, как хотелось...

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

Принцип Треугольника управления проектами

Треугольник управления проектами является одной основных концепций проектного управления, которая в виде треугольника описывает баланс между требованиями, бюджетом, сроками и качеством работ.

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

В случае,если невозможно увеличить бюджет, то остается только жертвовать качеством, как это изображено на схеме:

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

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

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

Принцип: "Быстро, дешево, качественно - выбирайте любые два пункта"

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

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

Это правило включает в себя четыре простых утверждения:

1. быстро + дешево = некачественно;
2. качественно + дешево = долго;
3. быстро + качественно = дорого;
4. быстро + дешево + качественно = утопия;

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

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

Принцип: "Желания безграничны, а возможности ограничены"

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

Этому правилу соотношения желаний и возможностей меня обучили еще в колледже (на каком точно предмете не помню, но вроде "Менеджмент"), а вообще это правило широко знакомо профессиональным менеджерам.

Любопытно, но многим известна одна из интерпретаний этого принципа из фильма "Кавказская пленница, или Новые приключения Шурика" в форме общеизвестной фразы: "Так выпьем же за то, чтоб наши желания совпадали с нашими возможностями!"

Это очень универсальное в быту правило, которое подходит и к разработке программного обеспечения. При расчете человеко-часов на выполнение какой-то части проекта, должны трезво оцениваться границы возможностей (временных, ресурсных, правовых, интелллектуальных и пр.), которые вам доступны.

Заключение

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

В случае с клиентами все понятно, но с менеджером, который зарабатывает на проценте с продаж, все хитрее, поскольку ему важно любыми способами продать ваш результат труда. И если вы оценили какую-нить доработку в 100 реальных часов, а менеджер понимает, что оплату больше 70 часов он клиенту не сможет продать, то менеджер может попытаться продавить разработчиков, в стиле "да что там такого делать 100 часов, там работы-то на пару часов!". А у разработчиков потом начинаются переработки, нервняк, выгорание и пр. и вероятнее всего, эти выторгованные 30 часов будут компенсироваться из своего личного времени, а оно вам надо? Поэтому если вы оказались в подобной ситуации, вспомните про вышеописанные принципы, принимайте разумное решение и поберегите свои нервы и здоровье.

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

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