В управлении большими веб-проектами чаще всего применяют принципы классического американского project management — щепитильное создание плана работы и четкое его выполнение. Строгие отчеты, хитрые графики и презентации в power point (утрирую).
Как оппозицию, все чаще ставят принципы Agile software development, где ленивые для документаций программисты (утрирую) в приоритеты ставят само написание кода и конечный продукт.
Я никогда не был ярым поклонником первого метода, но и со вторым имею много противоречий. Заинтересовавшись теорией управления я написал собственное видение известного agile manifesto — Agile manifesto (human remix). Расшифровка четырех идей манифеста с позиции того, что все мы люди. Пусть даже и работаем за деньги.
Классический project management учит заранее планировать возможные изменения в проекте. И в основном это касается негативных ситуаций — риски, опоздания, запасные пути. Но представьте, что посреди работы над проектом, появились неизвестные ранее возможности улучшить его: появились новые механизмы, стали доступны закрытые ресурсы или информация. Игнорировать подарок небес или перекроить весь план шиворот на выворот? А ведь выбор может напрямую повлиять на конкурентноспособность и прибыль конечного продукта.
Разгадка в том, что project management не создавался для руководства веб-проектами. Изменение окружающей среды в интернете куда более обычное явление, чем в строительстве или торговле. Назовите меня паршивым руководителем, потому что я редко завершаю веб-проект в те сроки, что давал перед началом работы. Я это делаю не самовольно: все боссы ставятся перед выбором — либо мы идем по графику и смотрим на конкурентов снизу-вверх, либо мы увеличиваем сроки в н-дцать раз и во столько же увеличиваем прибыль.
Боссы идут на изменения и продление сроков. У веб-проектов, по сути, нет сроков. За редким исключением не бывает жестких дедлайнов, а все даты являются выдумкой здравого смысла, ограничений бюджета и личных пожеланий заказчика. Если у вас есть причины — не бойтесь менять сроки, ничего не бойтесь менять.
Обсуждение этого пункта плавно перетекает из предыдущего — каким бы ни был контракт, всегда найдется ситуация, когда его невыполнение выгодно обеим сторонам.
Если вы фотограф-фрилансер, и из-за болезни не смогли отправиться в альпийские горы снимать горных козлов. В контракте написано «сфотографировать горных козлов» и вы можете выполнить его буквально в ближайшем зоопарке, но кому нужно такое выполнение контракта? Может лучше разорвать сделку? Заказчику посоветовать другого фотографа и не пятнать свою репутацию.
Или обратная ситуация с классическим примером, когда клиент просит «поменять цвет на нейтрально-синий». Каждый второй дизайнер гневно кивает на подписанный макет с коричневой гаммой и слышать не хочет об изменениях. Это выглядит смешно, когда речь идет о домашней страничке. Но если клиент владелец крупной социальной сети, и он уже год назад уволил того менеджера подписавшего коричневый макет — дизайнеру выгоднее выполнить сверхконтрактное усилие.
Большая часть людей в веб-бизнесе утверждает, что им нравится их работа, что деньги не единственный критерий. Так будьте людьми! Смотрите не на бумажку с контрактом, а на собеседника. Ругайтесь, спорьте, уговаривайте, верьте, обманывайте и обижайтесь. Живите!
И в первую очередь это касается рядовых работников проекта. В классическом project management есть мерзкая единица человеко-часов. Через эту единицу вычисляются все ключевые сроки проекта и большая часть бюджета. Но доверять основной документ абстрактным величинам — это все равно, что золотой песок жменьками продавать.
В веб-разработке вы работаете с дизайнерами — которые по своей сути художники-ван-гоги, — и с программистами — которые еще более чокнутые и фривольные математики-энштейны. О какой такой системе, о каких процессах и правилах вы можете говорить в этом диком обществе? Забудьте!
Я тысячу раз говорил и еще раз повторюсь: у меня, как у руководителя, нет абстрактных трех программистов на полный рабочий день. У меня есть Эрик, Ахмет и Сережа — живые люди со всеми своими достоинствами и недостатками. Когда я вычисляю сроки проекта, у меня нет человеко-часов, но у меня есть Эрик в скайпе. Когда я выдаю задание, у меня нет «формы задачи в формате эксель» — Сереже я все объясняю на пальцах.
Эти трое вымышленные персонажи, но в моей практике есть прекрасный пример в точных цифрах:
На одном из новостных сайтов работал бильд-редактор. Обязанность бильд-редактора — рисовать иллюстрации к новостям. Поскольку новостей много, то иллюстрации шли не ко всем, а только к избранным. До моего прихода в проект, у бильд-редактора даже в договоре было записано: 2 иллюстрации в день, и рисуемые новости указывает главный редактор. Так и сидел человек в офисе, выдавая десять картинок за неделю.
После моего появления в проекте и знакомства с бильд-редактором, я переделал договор. Убрал обязательный лимит в две картинки и отдал художнику право самому выбирать иллюстрируемые новости. Человек почуствовал свободу, расслабился, и в течении года выдавал не менее восемнадцати картинок в неделю. Эффективность — 180% за те же деньги и при неизменном качестве.
Расскажу еще одну, грустную но правдивую историю:
Шесть лет назад, заканчивая работу в одном из проектов, я написал исчерпывающее руководство своему преемнику. Список всех проблем и их решений, советы по оптимизации и дальнейшей модернизации, адреса-пароли-явки и слабые места ключевых чиновников — огромный труд, поскольку мне очень хотелось долгой жизни моему детищу.
Смена руководителя прошла на отлично, и проект не застопорился ни на секунду. А через два месяца ушел ведущий программист и проект умер.
Я обожаю документацию, я пишу тонны инструкций всем кому нужно и не нужно, я считаю что веб это и есть одна большая документация. Но в отличие от адептов церкви project managementа, я не отдаю канцелярии ключевую роль. Я видел много проектов, — и это были большие, прибыльные проекты — которые создавались в режиме анархии. Я видел как многие компании, — работающие по системе — просто напросто не справлялись с ростом и временем.
Но и к программистам, следующим agile manifesto, я не могу себя отнести — не тот характер. И тем не менее я руководитель веб-проектов.
Вчера я узнал почему тот ведущий программист ушел из проекта. Ему стало скучно после моего ухода! Мы никогда с ним не были друзьями, спорили, жаловались начальству друг на друга, помогали в делах — мы просто поддерживали человеческие отношения в общении. А такой простой инструкции своему преемнику — «будь человеком» — я написать не смог.
Как оппозицию, все чаще ставят принципы Agile software development, где ленивые для документаций программисты (утрирую) в приоритеты ставят само написание кода и конечный продукт.
Я никогда не был ярым поклонником первого метода, но и со вторым имею много противоречий. Заинтересовавшись теорией управления я написал собственное видение известного agile manifesto — Agile manifesto (human remix). Расшифровка четырех идей манифеста с позиции того, что все мы люди. Пусть даже и работаем за деньги.
Реакция на изменения важнее, чем следование плану
Классический project management учит заранее планировать возможные изменения в проекте. И в основном это касается негативных ситуаций — риски, опоздания, запасные пути. Но представьте, что посреди работы над проектом, появились неизвестные ранее возможности улучшить его: появились новые механизмы, стали доступны закрытые ресурсы или информация. Игнорировать подарок небес или перекроить весь план шиворот на выворот? А ведь выбор может напрямую повлиять на конкурентноспособность и прибыль конечного продукта.
Разгадка в том, что project management не создавался для руководства веб-проектами. Изменение окружающей среды в интернете куда более обычное явление, чем в строительстве или торговле. Назовите меня паршивым руководителем, потому что я редко завершаю веб-проект в те сроки, что давал перед началом работы. Я это делаю не самовольно: все боссы ставятся перед выбором — либо мы идем по графику и смотрим на конкурентов снизу-вверх, либо мы увеличиваем сроки в н-дцать раз и во столько же увеличиваем прибыль.
Боссы идут на изменения и продление сроков. У веб-проектов, по сути, нет сроков. За редким исключением не бывает жестких дедлайнов, а все даты являются выдумкой здравого смысла, ограничений бюджета и личных пожеланий заказчика. Если у вас есть причины — не бойтесь менять сроки, ничего не бойтесь менять.
Реакция на изменения в планах — одно из преимуществ человека над роботами.
Сотрудничество с заказчиком важнее, чем контрактные обязательства
Обсуждение этого пункта плавно перетекает из предыдущего — каким бы ни был контракт, всегда найдется ситуация, когда его невыполнение выгодно обеим сторонам.
Если вы фотограф-фрилансер, и из-за болезни не смогли отправиться в альпийские горы снимать горных козлов. В контракте написано «сфотографировать горных козлов» и вы можете выполнить его буквально в ближайшем зоопарке, но кому нужно такое выполнение контракта? Может лучше разорвать сделку? Заказчику посоветовать другого фотографа и не пятнать свою репутацию.
Или обратная ситуация с классическим примером, когда клиент просит «поменять цвет на нейтрально-синий». Каждый второй дизайнер гневно кивает на подписанный макет с коричневой гаммой и слышать не хочет об изменениях. Это выглядит смешно, когда речь идет о домашней страничке. Но если клиент владелец крупной социальной сети, и он уже год назад уволил того менеджера подписавшего коричневый макет — дизайнеру выгоднее выполнить сверхконтрактное усилие.
Большая часть людей в веб-бизнесе утверждает, что им нравится их работа, что деньги не единственный критерий. Так будьте людьми! Смотрите не на бумажку с контрактом, а на собеседника. Ругайтесь, спорьте, уговаривайте, верьте, обманывайте и обижайтесь. Живите!
«Ты хочешь, чтобы я бросил магнитофон в воду? Хорошо, я сделаю это.» (не сделал)
Личности и их взаимодействия важнее, чем процессы и инструменты
И в первую очередь это касается рядовых работников проекта. В классическом project management есть мерзкая единица человеко-часов. Через эту единицу вычисляются все ключевые сроки проекта и большая часть бюджета. Но доверять основной документ абстрактным величинам — это все равно, что золотой песок жменьками продавать.
В веб-разработке вы работаете с дизайнерами — которые по своей сути художники-ван-гоги, — и с программистами — которые еще более чокнутые и фривольные математики-энштейны. О какой такой системе, о каких процессах и правилах вы можете говорить в этом диком обществе? Забудьте!
Я тысячу раз говорил и еще раз повторюсь: у меня, как у руководителя, нет абстрактных трех программистов на полный рабочий день. У меня есть Эрик, Ахмет и Сережа — живые люди со всеми своими достоинствами и недостатками. Когда я вычисляю сроки проекта, у меня нет человеко-часов, но у меня есть Эрик в скайпе. Когда я выдаю задание, у меня нет «формы задачи в формате эксель» — Сереже я все объясняю на пальцах.
Эти трое вымышленные персонажи, но в моей практике есть прекрасный пример в точных цифрах:
На одном из новостных сайтов работал бильд-редактор. Обязанность бильд-редактора — рисовать иллюстрации к новостям. Поскольку новостей много, то иллюстрации шли не ко всем, а только к избранным. До моего прихода в проект, у бильд-редактора даже в договоре было записано: 2 иллюстрации в день, и рисуемые новости указывает главный редактор. Так и сидел человек в офисе, выдавая десять картинок за неделю.
После моего появления в проекте и знакомства с бильд-редактором, я переделал договор. Убрал обязательный лимит в две картинки и отдал художнику право самому выбирать иллюстрируемые новости. Человек почуствовал свободу, расслабился, и в течении года выдавал не менее восемнадцати картинок в неделю. Эффективность — 180% за те же деньги и при неизменном качестве.
На одного вольнодумающего Рэмбо приходилось пол сотни вражеских солдат, слепо выполнявших приказы генералов.
Работающее программное обеспечение важнее, чем полная документация
Расскажу еще одну, грустную но правдивую историю:
Шесть лет назад, заканчивая работу в одном из проектов, я написал исчерпывающее руководство своему преемнику. Список всех проблем и их решений, советы по оптимизации и дальнейшей модернизации, адреса-пароли-явки и слабые места ключевых чиновников — огромный труд, поскольку мне очень хотелось долгой жизни моему детищу.
Смена руководителя прошла на отлично, и проект не застопорился ни на секунду. А через два месяца ушел ведущий программист и проект умер.
Я обожаю документацию, я пишу тонны инструкций всем кому нужно и не нужно, я считаю что веб это и есть одна большая документация. Но в отличие от адептов церкви project managementа, я не отдаю канцелярии ключевую роль. Я видел много проектов, — и это были большие, прибыльные проекты — которые создавались в режиме анархии. Я видел как многие компании, — работающие по системе — просто напросто не справлялись с ростом и временем.
Но и к программистам, следующим agile manifesto, я не могу себя отнести — не тот характер. И тем не менее я руководитель веб-проектов.
Система project managementa с его отчетами-таблицами-графиками — как бы, синяя таблетка матрицы. Вольные agile-программисты с их талантом и нелюбовью к системе — как бы, красная таблетка Нео. Существуют ли варианты?
Вчера я узнал почему тот ведущий программист ушел из проекта. Ему стало скучно после моего ухода! Мы никогда с ним не были друзьями, спорили, жаловались начальству друг на друга, помогали в делах — мы просто поддерживали человеческие отношения в общении. А такой простой инструкции своему преемнику — «будь человеком» — я написать не смог.
