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



Делегирование — один из базовых инструментов руководителя, о котором большинство знает. Но обращаются к нему часто слишком поздно, считая, что «ещё не пришло время делегировать — других дел полно». К сожалению, это может привести к не очень хорошим результатам.

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

Добро пожаловать под кат!

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

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

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

Исходные данные нашего отдела: небольшая (5–10 человек), частично распределенная (некоторые сотрудники работают удаленно, некоторые в офисе) продуктовая команда с заказчиками внутри самой компании. Веб-проекты. Нет специалистов по системному администрированию внутри отдела, но есть занимающиеся этим отделы в компании.

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

Прелесть в том, что живые люди сами не пытаются тебя учить. Не проводят семинаров, тренингов, не берут с тебя денег. Они просто делают свою работу, как умеют. Что-то у них получается, бывают и провалы, и срывы, и ругань с матами. Но у каждого можно чему-то научиться, даже если в целом о человеке мнение складывается негативное.

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

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

В комментариях велели картинку для привлечения внимания вставить. Исполняю.



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

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

Работая более 20 лет в IT-индустрии, каждую новую разработку я начинал строить с проектного офиса. Более того, несколько раз мне приходилось объяснять руководству, зачем нанимать пиэмов. При наличии руководителей отделов, не так просто объяснить людям, которые не принимают непосредственного участия в разработке софта, что же именно будут делать менеджеры проектов. Приходилось преодолевать заметное сопротивление.

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

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

Когда ты устроился в компанию на позицию Junior Developer, ты смотришь вокруг и видишь, с какой лёгкостью старшие товарищи забивают на шаблоны и пишут два одинаковых класса с разными типами переменных. Как они хардодят размеры вьюшек в коде. Как они читают хабр на работе. И ты точно знаешь, что когда вырастешь до Senior Developer-а, ты будешь лучше, надёжнее, ответственнее, любой блок твоего кода можно будет показывать потомкам.

Ты уже три года проработал программистом, ты (возможно) всё более и более пристально смотришь в сторону проджект менеджмента. Твой ПМ уже не царь, и не бог, и его работа не кажется тебе сложной и непонятной. Ты видишь, что работаешь намного больше его, а он ленится сделать тебе Code Review и похвалить за оригинальную интеграцию сторонней библиотеки. Он даже не смотрит на твой идеальный код в сложнейшей стыковке кривого API и мутной бизнес-логики. И ты точно знаешь, что, когда тебе улыбнётся удача руководить проектом, ты всё будешь делать лучше. Ты будешь бережнее следить за своими девелоперами, ревьювить каждый их класс, хвалить за удачные решения и порицать за очевидные ошибки.

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


«Два типа людей в эксплуатации: кто уже сломал production, кто ещё только собирается это сделать»

Опубликованная 10 дней назад заметка собрала более 23 тысяч положительных голосов на Reddit и разошлась по другим специализированным ресурсам вроде The New Stack. Суть истории такова:

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

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


Источник

Предыстория

Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?

1. Мир пытается оставить тебя тупым. Начиная от банковских платежей и процентов и заканчивая чудо-диетами — из необразованных людей легче вытрясти деньги и ими проще управлять. Занимайтесь самообразованием столько, сколько можете — для того, чтобы быть богатым, независимым и счастливым.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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