Давно подметил, что веб-проекты отличаются разными классами «свежести»…
Программисты редко уходят из таких проектов, т.к. удовольствие от возможности работать с правильным кодом и разумной архитектурой нередко подавляет периодические позывы о повышении зарплаты и карьерном росте. Человек может реально трудиться и три, и пять лет, особенно если ему дают возможность стать сопричастным продукту и добавить в него часть своего мозга и сердца.
Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)
Техническая поддержка занимается исправлением незначительных ошибок, собирая в основном в приоритезированные букеты пожелания клиентов.
Короче ощущается что-то вроде благоухания и благоговения, причем это отмечают все — и топы, и менеджеры, и разработчики, и саппорт.
К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.
Программисты всеми правдами и неправдами пытаются протиснуться и перескочить на задачи, связанные с «правильными» модулями/компонентами продукта. Там действительно порядочек, чисто и есть желание добавлять что-то новое, проявить творчество.
У групп разработчиков, занимающихся развитием определенных, назовем их «загнивающих» частей продукта, начинают проявляться признаки деморализации, перепады настроения, сарказм относительно «генетических дураков, которые писали данный модуль» или «слабохарактерных менеджеров, проглатывающих спускаемые сверху или сбоку сроки, независимо от мнения команды разработки». Замечаются разговоры на тему «надо срочно переписать блок/модуль с нуля пока еще не поздно».
Разброс оценок задач, связанных с доработкой «загнивающих» частей — достаточно велик, что увеличивает риски поступательного развития продукта в данном направлении. В принципе менеджеры уже начинают нервничать, кричать на разработчиков, вспыхивают пожары локальной текучки кадров.
Саппорт еще держит оборону, закрывая проблемные места продукта летними студентами на 3 месяца либо сотрудниками с отсутствием нервной системы.
Периодически коллеги отмечают обонятельные признаки фрагментального появления мертвеца, но считают их временными (менеджеры, программисты скорее всего уже кричат о проблеме и тушат пожар, надеясь быть услышанными).
Самое странное в этой ситуации, что определенные группы проектного менеджмента, иногда топы, намеренно носят марлевые повязки и беруши в ушах, выдавливая из себя перед клиентами лживую улыбку. Видимо привыкли работать в компаниях не более 2-3 лет, поэтому им просто наплевать на надвигающуюся беду.
А представляете, в таких проектах оказываются могут работать программисты! Но это как правило особые личности:
1) Сумасшедшие гении. Коллеги, можно сказать, занимаются доведением до совершенства крошечных кусочков продукта, наслаждаются от этого, совершенно искренне не замечая ужасного трупного зловония и проникновения жидкостей разложения под одежду. Им неважно, делать маникюр прекрасной девушке или красить ноготки небрежно оторванной ступне :-)
2) Тролли на прокачке. Коллеги вдохновляются экстремальным бардаком и прокачивают свои знания в области XP и паттернов проектирования на обильно представленном биоматериале. Разумеется никто и не думает о рефакторинге, тем более модульности — просто рубка.
3) Студенты. Ребятам нужно получить любой опыт любой ценой. Ну что страшного, если они сломают вам биллинг в 75 местах и на практике начнут отличать вторую нормальную форму от третьей, безвозвратно потеряв пару финансовых транзакций и отправив по клиентскому списку из 5000 адресов рассылку: «Test!!! Fuck1 — ok, fuck2 — error, fuck3 — null».
В вашей команде разработки будет большая текучка, придется людей заманивать — но, внимание, оставаться люди все же будут. Правда работать — вряд ли.
«Военные медики» — это, пожалуй, единственный тип менеджеров, которые будут пытаться выправить в таком проекте ситуацию, проводя ежечасовые ампутации и утренние дефибрилляции. Коллеги будут биться головой об стенку, адекватно понимая что происходит, но, как правило, их надолго не хватает и они увольняются сами. Некоторые, особо храбрые «военные медики», смогут успеть сказать вышестоящему руководству что проект пора закрывать, что это бюджетная дыра — за что скорее всего окончат день с обходным листом в отделе кадров.
«Маньяки» — в таких экстремальных проектах откуда ни возьмись появляются менеджеры, которым… оказывается ПРОСТО нравится. Они будут бежать на работу и до позднего вечера, «стоя на лодке», методично добивать барахтающися в «болоте» разработчиков и нижестоящих менеджеров веслом.
«Прокси с чувством юмора». Данные коллеги, обладая полномочиями и распоряжаясь ресурсами и надеясь проработать в компании 2-3 года поступают просто — нанимают и увольняют. А еще развлекаются, сталкивая «военных медиков» друг с другом (а если столкнуть с «маньяком» — еще интереснее). Разумеется — никто и думать не собирается про конечный результат, тем более считать деньги. Просто, имея пяток таких проектов, можно играться в прокси 2-3 года, пока поймут твою политику.
А как же антикризисные менеджеры? :-) Убежден, они должны приходить в продукты «второй свежести» — а тут уже скорее всего ничего не изменишь.
Если вам посчастливилось начать веб-проект с нуля, то это вполне достижимая задача. Но если вам достался продукт «второй свежести» — тоже не все упущено.
Для этого нужно построить «холодильник», не дающий продукту протухнуть — систему жесткого контроля качества и мотивации.
Нужно понять, что о качестве можно много говорить, писать, бегать с тряпочкой и вытирать пыль, но всегда есть МИНИМУМ, ниже которого планка качества в продукте никогда не должна надолго опускаться. Научитесь спинным мозгом чувствовать этот критерий — не чувствуете? придет с опытом — интуиция развивается.
А пока придерживайтесь простых, проверенных опытом правил:
1) Не пытайтесь найти много хороших программистов. Постарайтесь найти одного и пусть он стоит в 2-3 раза дороже. Остальные могут быть студентами, начинающими, средними и т.п. — согласно бюджету проекта.
2) Если проект имеет сложную бизнес-логику, биллинг и т.п. — воспользуйтесь готовым решением/фреймворком (ZendFramework, BitrixFramework и т.п.) — чтобы ничего сложного вам делать не пришлось. Если не получается — обязательно найдите одного, хорошего, системного аналитика.
3) Данные коллеги не должны ничего создавать. Их задача — жесткий контроль и отсев. Через них либо проходят код, АПИ, архитектура — либо не проходят и без компромиссов. Да, по началу у вас будет кадровая текучка но затем, останутся люди (либо вышеуказанные специалисты их воспитают), которые сумеют делать вещи, пропускаемые через вышестоящий фильтр качества и здравого смысла.
4) Каждый день спрашивайте коллег-экспертов:
— Создаваемый продукт модульный? Ожидаемый ответ: Да или поставлена задача на рефакторинг.
5) Следите, чтобы определенный процент времени всегда выделялся на рефакторинг (изменение кода БЕЗ добавления нового функционала). Это ОЧЕНЬ важно.
6) Если эксперты вам говорят, что разработчики умеют писать модульные тесты — разрешите им это делать. Значит вам повезло. Если не умеют и не учатся — не беда. Нас спасет модульность.
7) Не бойтесь тестировать проект на… сотрудниках вашей компании и определенных группах клиентов. Чем больше найдете глаз, тем лучше. Поймите, вам никогда НЕ ДАДУТ сформировать отдел тестирования со штатом в 100 и более человек :-)
8) Чеклисты. Удивительно эффективный инструмент он-лайн поддержания качества процессов на приемлемом уровне, имеющий прямой аналог в… боевом армейском уставе. Несоблюдение пункта — и полголовы солдата разбрызгиваются в радусе 5 метров. Пишите и развивайте чеклисты: от программирования и правил аудита безопасности кода, до процессов выкладки изменений проекта на боевые сервера.
9) Берегите вашу проектную команду всеми силами — как от коллег, так и от топов. Хвалите и поощряйте творчество, создайте атмосферу Жизни. Не давайте никому безнадежно сломать «холодильник», сохраняющий ваш продукт/проект свежим.
Не падайте духом, если ваш проект стал все таки протухать — постарайтесь как можно быстрее вернуть его в свежее состояние, увеличив время на рефакторинг и сдержав внешнее давление неадекватных сроков и меняющихся требований. У вас обязательно получится.
Удачи!
Первой свежести
Программисты редко уходят из таких проектов, т.к. удовольствие от возможности работать с правильным кодом и разумной архитектурой нередко подавляет периодические позывы о повышении зарплаты и карьерном росте. Человек может реально трудиться и три, и пять лет, особенно если ему дают возможность стать сопричастным продукту и добавить в него часть своего мозга и сердца.
Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)
Техническая поддержка занимается исправлением незначительных ошибок, собирая в основном в приоритезированные букеты пожелания клиентов.
Короче ощущается что-то вроде благоухания и благоговения, причем это отмечают все — и топы, и менеджеры, и разработчики, и саппорт.
К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.
Второй свежести
Программисты всеми правдами и неправдами пытаются протиснуться и перескочить на задачи, связанные с «правильными» модулями/компонентами продукта. Там действительно порядочек, чисто и есть желание добавлять что-то новое, проявить творчество.
У групп разработчиков, занимающихся развитием определенных, назовем их «загнивающих» частей продукта, начинают проявляться признаки деморализации, перепады настроения, сарказм относительно «генетических дураков, которые писали данный модуль» или «слабохарактерных менеджеров, проглатывающих спускаемые сверху или сбоку сроки, независимо от мнения команды разработки». Замечаются разговоры на тему «надо срочно переписать блок/модуль с нуля пока еще не поздно».
Разброс оценок задач, связанных с доработкой «загнивающих» частей — достаточно велик, что увеличивает риски поступательного развития продукта в данном направлении. В принципе менеджеры уже начинают нервничать, кричать на разработчиков, вспыхивают пожары локальной текучки кадров.
Саппорт еще держит оборону, закрывая проблемные места продукта летними студентами на 3 месяца либо сотрудниками с отсутствием нервной системы.
Периодически коллеги отмечают обонятельные признаки фрагментального появления мертвеца, но считают их временными (менеджеры, программисты скорее всего уже кричат о проблеме и тушат пожар, надеясь быть услышанными).
Самое странное в этой ситуации, что определенные группы проектного менеджмента, иногда топы, намеренно носят марлевые повязки и беруши в ушах, выдавливая из себя перед клиентами лживую улыбку. Видимо привыкли работать в компаниях не более 2-3 лет, поэтому им просто наплевать на надвигающуюся беду.
Помойка
А представляете, в таких проектах оказываются могут работать программисты! Но это как правило особые личности:
1) Сумасшедшие гении. Коллеги, можно сказать, занимаются доведением до совершенства крошечных кусочков продукта, наслаждаются от этого, совершенно искренне не замечая ужасного трупного зловония и проникновения жидкостей разложения под одежду. Им неважно, делать маникюр прекрасной девушке или красить ноготки небрежно оторванной ступне :-)
2) Тролли на прокачке. Коллеги вдохновляются экстремальным бардаком и прокачивают свои знания в области XP и паттернов проектирования на обильно представленном биоматериале. Разумеется никто и не думает о рефакторинге, тем более модульности — просто рубка.
3) Студенты. Ребятам нужно получить любой опыт любой ценой. Ну что страшного, если они сломают вам биллинг в 75 местах и на практике начнут отличать вторую нормальную форму от третьей, безвозвратно потеряв пару финансовых транзакций и отправив по клиентскому списку из 5000 адресов рассылку: «Test!!! Fuck1 — ok, fuck2 — error, fuck3 — null».
В вашей команде разработки будет большая текучка, придется людей заманивать — но, внимание, оставаться люди все же будут. Правда работать — вряд ли.
Менеджмент. Тут театр абсурда.
«Военные медики» — это, пожалуй, единственный тип менеджеров, которые будут пытаться выправить в таком проекте ситуацию, проводя ежечасовые ампутации и утренние дефибрилляции. Коллеги будут биться головой об стенку, адекватно понимая что происходит, но, как правило, их надолго не хватает и они увольняются сами. Некоторые, особо храбрые «военные медики», смогут успеть сказать вышестоящему руководству что проект пора закрывать, что это бюджетная дыра — за что скорее всего окончат день с обходным листом в отделе кадров.
«Маньяки» — в таких экстремальных проектах откуда ни возьмись появляются менеджеры, которым… оказывается ПРОСТО нравится. Они будут бежать на работу и до позднего вечера, «стоя на лодке», методично добивать барахтающися в «болоте» разработчиков и нижестоящих менеджеров веслом.
«Прокси с чувством юмора». Данные коллеги, обладая полномочиями и распоряжаясь ресурсами и надеясь проработать в компании 2-3 года поступают просто — нанимают и увольняют. А еще развлекаются, сталкивая «военных медиков» друг с другом (а если столкнуть с «маньяком» — еще интереснее). Разумеется — никто и думать не собирается про конечный результат, тем более считать деньги. Просто, имея пяток таких проектов, можно играться в прокси 2-3 года, пока поймут твою политику.
А как же антикризисные менеджеры? :-) Убежден, они должны приходить в продукты «второй свежести» — а тут уже скорее всего ничего не изменишь.
А можно поддерживать продукт всегда в «первой свежести»?
Если вам посчастливилось начать веб-проект с нуля, то это вполне достижимая задача. Но если вам достался продукт «второй свежести» — тоже не все упущено.
Для этого нужно построить «холодильник», не дающий продукту протухнуть — систему жесткого контроля качества и мотивации.
Нужно понять, что о качестве можно много говорить, писать, бегать с тряпочкой и вытирать пыль, но всегда есть МИНИМУМ, ниже которого планка качества в продукте никогда не должна надолго опускаться. Научитесь спинным мозгом чувствовать этот критерий — не чувствуете? придет с опытом — интуиция развивается.
А пока придерживайтесь простых, проверенных опытом правил:
1) Не пытайтесь найти много хороших программистов. Постарайтесь найти одного и пусть он стоит в 2-3 раза дороже. Остальные могут быть студентами, начинающими, средними и т.п. — согласно бюджету проекта.
2) Если проект имеет сложную бизнес-логику, биллинг и т.п. — воспользуйтесь готовым решением/фреймворком (ZendFramework, BitrixFramework и т.п.) — чтобы ничего сложного вам делать не пришлось. Если не получается — обязательно найдите одного, хорошего, системного аналитика.
3) Данные коллеги не должны ничего создавать. Их задача — жесткий контроль и отсев. Через них либо проходят код, АПИ, архитектура — либо не проходят и без компромиссов. Да, по началу у вас будет кадровая текучка но затем, останутся люди (либо вышеуказанные специалисты их воспитают), которые сумеют делать вещи, пропускаемые через вышестоящий фильтр качества и здравого смысла.
4) Каждый день спрашивайте коллег-экспертов:
— Создаваемый продукт модульный? Ожидаемый ответ: Да или поставлена задача на рефакторинг.
5) Следите, чтобы определенный процент времени всегда выделялся на рефакторинг (изменение кода БЕЗ добавления нового функционала). Это ОЧЕНЬ важно.
6) Если эксперты вам говорят, что разработчики умеют писать модульные тесты — разрешите им это делать. Значит вам повезло. Если не умеют и не учатся — не беда. Нас спасет модульность.
7) Не бойтесь тестировать проект на… сотрудниках вашей компании и определенных группах клиентов. Чем больше найдете глаз, тем лучше. Поймите, вам никогда НЕ ДАДУТ сформировать отдел тестирования со штатом в 100 и более человек :-)
8) Чеклисты. Удивительно эффективный инструмент он-лайн поддержания качества процессов на приемлемом уровне, имеющий прямой аналог в… боевом армейском уставе. Несоблюдение пункта — и полголовы солдата разбрызгиваются в радусе 5 метров. Пишите и развивайте чеклисты: от программирования и правил аудита безопасности кода, до процессов выкладки изменений проекта на боевые сервера.
9) Берегите вашу проектную команду всеми силами — как от коллег, так и от топов. Хвалите и поощряйте творчество, создайте атмосферу Жизни. Не давайте никому безнадежно сломать «холодильник», сохраняющий ваш продукт/проект свежим.
Не падайте духом, если ваш проект стал все таки протухать — постарайтесь как можно быстрее вернуть его в свежее состояние, увеличив время на рефакторинг и сдержав внешнее давление неадекватных сроков и меняющихся требований. У вас обязательно получится.
Удачи!
