Почему из новомодных систем управления проектами получается х..

Таск-менеджер – это не багтрекер, или Почему из новомодных систем управления проектами получается херня.

Каждый раз, когда я вижу очередной пост о том, что “Мы изобрели очередную канбан-доску”, у меня начинают чесаться кулаки и возникает подспудное желание придать автору ускорение в сторону ближайшей стены, – потому что я знаю, что пост закончится тем что “…а теперь мы попробуем научить в ней работать хоть кого-нибудь из других отделов кроме программистов”.

И получается херня. Потому что таск-менеджер – это не багтрекер. Continue reading “Почему из новомодных систем управления проектами получается х..”

Мониторинг сайта: как первым узнать, когда что-то сломалось

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

При этом, если вы с верстальщиками компетентны в плане корректного html-кода, то остальные участники могут тупо редактировать контент через “визуальный редактор” в админке, снося таким образом все тщательно выверенные стили и яваскрипты. Более того, я встречал менеджеров, которые даже не догадываются что когда два человека одновременно редактируют страницу – изменения одного из них всегда будут утеряны. Они уверены в том, что админка “сведёт” их правки воедино, как это сделали бы системы контроля исходного кода (svn). А если к сайту имеет доступ ещё и сам клиент..

Итак, вы менеджер по этому сайту, и у вас ум за разум заходит при попытке контролировать всё и вся. На вас выливают ушаты помоев за то, что на какой-то странице какая-то точка стоит не там где надо. По-хорошему надо было с самого начала писать тесты, но время утеряно, тестов нет, а контролировать надо прямо сейчас. Как? Continue reading “Мониторинг сайта: как первым узнать, когда что-то сломалось”

Победа в безнадёжных проектах: Вот поэтому я и поручил это именно тебе

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

Вам доверяют высокую цель, для вас это вызов, вопрос престижа и репутации. Вам придётся поверить в этот график и эти ресурсы. А почему бы и нет? Раньше ведь удавалось. Возможно, время покажет вашу ошибку, но в данный момент вы полностью вдохновлены на подвиги и у вас за спиной словно выросли крылья: вау, я смогу включить такой крутой проект в моё портфолио! Именно в этот момент вы делаете первый взмах лопатой, чтобы вырыть себе яму. Либо уверенно шагаете в ту яму, где уже находится проект.

Continue reading “Победа в безнадёжных проектах: Вот поэтому я и поручил это именно тебе”

Как управлять проектом при недостатке ресурсов

Весь свой опыт управления проектами и решения проблем я приобрёл из того, что ресурсов всегда не хватало, и нужно было шевелить мозгами и задницей чтобы достигать целей в рамках жёсткой конкуренции. Но ошибочно считать, что ресурсов реально не хватает везде и всегда: стартапы, госзаказы, подъёмные инвестиции в новые подразделения и так далее – есть масса противоположных случаев, когда ресурсов вполне достаточно с избытком. Когда я некоторое время работал в Москве, там была группа разработчиков в 22 человека – штатно, в офисе, и это только программисты! Никто особо не жаловался на нехватку людей.

Но в моей профильной области (сайты и веб-проекты) Continue reading “Как управлять проектом при недостатке ресурсов”

Закон сохранения работы

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

Continue reading “Закон сохранения работы”

Rework – бизнес без предрассудков

Очередная прекрасная книга от 37signals – авторов Getting Real, приверженцев GTD, евангелистов Ruby on Rails, гуру в области управления проектами. Книга must read каждому, кто работает в проектах в IT или любой другой сфере. Вот несколько цитат, которые позволят вам почувствовать основные мотивы:

Continue reading “Rework – бизнес без предрассудков”

Управляемый факап, или Как бежать быстрее медведя

– Это бесполезно! Мы не можем бежать быстрее медведя!
– А мне не нужно бежать быстрее медведя. Мне нужно бежать быстрее других туристов.
(Народная мудрость)

В наши дни множество людей, особенно среди молодёжи, каждый день приходя на работу – бьются головой о стенку от царящего в их фирмах перманентного факапа. Кто более инициативен – предлагает взять дело в свои руки, наладить порядок, нанять больше людей для решения скопившейся кучи задач. Кто попроще – тихо плывёт по течению, иногда вздыхая “как же бл..дь всё плохо”. В клинических случаях люди начинают грезить о волшебных Гуглах и Яндексах, где всегда светит солнце, всегда выполняются планы, и сотрудникам всегда поручают только интересные задачи. А на текущем месте работы все подчинённые втихаря костят руководство от менеджеров среднего звена до самых верхов.

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

Continue reading “Управляемый факап, или Как бежать быстрее медведя”

Лебедев заново изобрёл колесо

Тёма Лебедев заново изобрёл метод быстрого прототипирования, который он в своей дизайнерской манере назвал методом "прогрессивного джипега", хотя то что у него там на картинках – это вообще грузится gif, а не jpeg. Но не суть, потому что само быстрое прототипирование изобретено миллион лет назад и является одной из основных практик экономически эффективной разработки проектов (Agile).

Так работают во всём цивилизованном мире. Много лет я ищу в РФ хотя бы одну компанию, которая реально так работает "у нас". Но нет, заказчикам подавай готовый результат. Пока результат не достигнут – их не е..ут детали, а как только достигнут – выясняется что всё сделано совсем не так.

Люди! Покажите мне хоть одну компанию в СПб, которая работает на быстрых прототипах и ведёт проект вживую, а не на основе высеченных в камне (утверждённых заказчиком) дизайнерских макетов. Я с радостью пойду туда работать.
 
 

Два искусства менеджера

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

Второе искусство – это верно определить такой курс.

Про найм менеджеров

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

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

А у тебя просто бюджет на эту вакансию N в месяц, который надо освоить по госконтракту, и всё. И никому результат не нужен. Грустно? Да, грустно. Но это прекрасный критерий, чтобы отделить опытных менеджеров от неопытных. Опытный просто скажет "Нет".

Вспоминаю себя в аналогичной ситуации. В одном из случаев – в первый раз сказал "Нет", через два года сказал "Нет", и ещё через два года получил там же оклад в 6 (!) раз больше изначально предлагаемого. Во втором случае сказал "Нет" на предложение $3k в месяц, так как не поверил в фирму. В течение года фирма была продана другому владельцу и успешно заброшена.