HR-Journal.ru :: Опыт внедрения подхода Getting Real в управлении компанией NetCat
закрыть Х
Мы в соцсетях

Во всех наших группах мы делимся интересными постами, шутим и раздаём прочие вкусности ;)

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

Логин:

Пароль:

Регистрация
Забыли пароль?

Опыт внедрения подхода Getting Real в управлении компанией NetCat

© 05.12.2011
Дмитрий Васильев, директор компании NetCat

Это своего рода отчет о годовом опыте внедрения подхода Getting Real к управлению отдельно взятой компанией. Я делюсь собственным опытом в формате «тезис GR — как мы его поняли, реализовали, и что из этого получилось».

Справка:

Getting Real – подход, направленный на уменьшение формализма в управлении, сдвигающий акцент в управлении с формальных действий (отчёты, модели, совещания и т.д.) на итоговый результат.

Дмитрий Васильев – директор софтверной компании NetCat, разрабатывающей известную систему управления сайтами (CMS NetCat).

Год назад я прочитал книгу Getting Real от команды 37signals. Она очень впечатлила меня, и я решил, что стоит опробовать этот подход в нашей компании, чем и занялся прямо с начала 2011 года. Эта статья — своего рода отчет о годовом опыте внедрения подхода Getting Real в отдельно взятой компании. Отчет, конечно же, промежуточный, потому что о реальном эффекте от изменения подхода к работе можно судить спустя более ощутимый промежуток времени; к тому же, не все принципы подхода мы смогли применить. Об этом я тоже расскажу.

Я не буду пересказывать содержание книги; если вы не читали ее, но интересуетесь управлением разработкой, обязательно прочитайте, она выложена в открытом доступе. Книжка совсем короткая. Если понравится — советую прочитать Rework от тех же 37signals, эта книга уже пообъёмнее.

Прежде всего надо сказать, что Getting Real наиболее эффективен в стартапах, начинающих командах. У NetCat за спиной 12 лет существования, масса кода, написанного разными людьми в разное время, сложившиеся бизнес-процессы и большая партнерская сеть. С одной стороны, это мешает: создавать заново проще, чем перестраивать. А с другой — имея за плечами большой опыт, гораздо проще сравнивать достоинства и недостатки разных подходов и методик.

Не воспринимайте эту статью как руководство по внедрению или мастер-класс: я лишь делюсь собственным опытом в формате «тезис GR — как мы его поняли и реализовали, что из этого получилось».

Тезис «Оставайтесь маленькими»

Каждый сотрудник компании должен приносить прибыль, прямо или косвенно. Значит, чем больше сотрудников, тем больше прибыли — при правильной организации их труда. Это правило работает далеко не всегда, особенно в IT-индустрии. Существует огромное количество примеров, когда небольшие команды энтузиастов отъедали у гигантов отрасли большие куски рынка, а то и создавали свой собственный сегмент. У больших компаний априори отсутствует мобильность, зато в избытке бюрократия, а также:

  • Совещания

  • Документооборот

  • Фиксированные зарплатные ставки

  • Уровни доступа

  • Управленческие цепочки

  • Стратегическое планирование

  • Детальное проектирование

  • Штатное расписание

  • Система поощрений и наказаний

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

Раньше мы все время старались найти ресурсы для роста, ведь задач всегда больше, чем мы могли переварить. Наш продукт требует постоянного развития, в каждый момент существует множество задач, которые надо решать: создавать новые модули, усовершенствовать старые, выпускать отраслевые решения и так далее. Значит, нам нужно как можно больше программистов. В то же время, потенциальные партнеры нашей компании — это не только конечные пользователи сайтов, но и разработчики сайтов, хостинг-провайдеры, ритейлерские сети, розничные магазины. Значит, нужно брать больше менеджеров и маркетологов. Но что делать, если денег на расширение нет? Выходит, замкнутый круг?

С некоторых пор мы прекратили рост. Сейчас в компании работают 12 человек (на момент написания этой статьи 11, у нас вакансия программиста-стажера): программисты (4), сотрудники службы технической поддержки и сопровождения (4), менеджеры (3), проектировщик. Наши сотрудники в основном универсальны, они в той или иной степени могут выполнять работу своего соседа, если он заболеет или уйдет в отпуск. Однако, всю непрофильную работу мы стараемся отдавать на аутсорс. А иногда даже и профильную. Так, два из пяти вновь созданных модулей версии NetCat 4.5, вышедшей весной 2011 года, были созданы сторонними разработчиками. За восемь месяцев 2011 года мы работали на субподряде с пятью компаниями и девятью фрилансерами. На аутсорсе мы заказываем:

  • бухгалтерские и юридические услуги

  • дизайнерские работы

  • верстку

  • разработку (частично)

  • рекламные услуги, организацию событий

  • тестирование (частично)

  • аудит (юзабилити, безопасность)

  • администрирование наших серверов

  • уборку :)

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

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


 

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

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

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

Тезис «Меньше совещаний, больше свободы»

Совещания в книге Getting Real выставляются однозначно в негативном свете. Совещания со временем превращаются в потерю рабочего времени, пережевыванию ненужной информации, разбиванию рабочего дня и т.д. Мы решили последовать совету авторов. Мы проводим общие планерки раз в неделю-две, но не используем их для выдачи заданий и заслушиванию отчетов. На таких планерках те, кому есть что рассказать, делают это в свободной форме. Техподдержка рассказывает о своей загрузке, о необычных обращениях; руководство — о ближайших планах и проблемах, другие люди — о предстоящих мероприятиях, текущей финансовой ситуации и пр. Также на планерках обсуждается, купить ли теннисный стол в офис, поедем ли мы вместе в следующие выходные на дачу к одному из нас, что надо сменить марку кофе, потому что та, которая в кофемашине — кислая и пр. Таким образом, все сотрудники в курсе общей ситуации в компании, не возникает вопросов «кто чем занимается» или «зачем мы это делаем». Каждый человек может высказать свое мнение по любому вопросу, даже если он не входит в его компетенцию. Хотя решения все равно принимаются теми, кто отвечает за эти решения.

Если требуется обсудить что-то конкретное, то на встречу приходят только те, кто будет на ней полезен. Когда у проектировщика возникает вопрос к разработчикам на тему сложности реализации какого-то интересного функционала, он зовет ведущего разработчика «прямо сейчас»; если для решения вопроса требуется участие большого количества сотрудников, назначаем время «через час» или «завтра».

Также мы отказались от фиксированного рабочего дня для основной части сотрудников. У нас только три человека обязаны быть в офисе с десяти часов: дежурный сотрудник техподдержки, менеджер-администратор и менеджер по работе с партнерами. Это те роли, которые действительно нужны в течение общепринятого рабочего дня. Все остальные работают в том режиме, которым им удобен. Мы опасались, что это приведет к появлению «халявщиков», которые ничего не делают, а только получают зарплату. Такие действительно были, но распознать их очень легко. Впрочем, для них и присутствие на рабочем месте не означает эффективной работы. Зато остальные чувствуют себя гораздо более комфортно, и это очень сильно влияет на эффективность работы. Если человек любит поспать подольше и лечь попозже, зачем его ломать? Если какой-то важный кусок программы сотрудник хочет написать дома, где ему не мешают коллеги, зачем заставлять его сидеть в офисе?

Тезис «Нанимайте меньше и реже»

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

Конечно, такой подход является спорным. Его недостаток в следующем. Беря на работу неопытного сотрудника, мы фактически покупаем кота в мешке, ведь мы можем ошибиться в оценке его потенциала. В этом случае через несколько недель или месяцев человек уходит из компании, а ведь мы вложили в него время и деньги. С этим приходится мириться. Иногда возникает обратная ситуация: сотрудник растет быстрее компании, ему уже не интересно сидеть на технической поддержке, а мы прямо сейчас не можем предложить ему рост. Такие ситуации еще более обидны, но создавать рабочие места под хороших людей — порочная практика.

Тезис «Будьте открытыми»

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

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

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

Тезис «Будьте собой»

Эта мысль проходит в книге красной нитью. Продукты нужно разрабатывать не для абстрактных пользователей, а для себя, чтобы вам самим было удобно ими пользоваться. Например, модуль «Минимагазин» (только функция помещения в корзину, управление ей, отправка заказа на email и архив заказов; никакого 1С-а, онлайн-оплаты, сравнения товаров и пр.; но подключается он к каталогу товаров за считанные минуты) я придумал год назад для сайта моей мамы, после чего мы решили выпустить его в продуктовой линейке. Сейчас по статистике продаж он занимает второе место после «Личного кабинета».

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

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

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


 

Мир глазами первой лошади в упряжке


 

Мир глазами второй лошади в упряжке

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

Тезис «Ограничения помогают»

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

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

Когда мы принимали решение о составе версии NetCat 4.5, мы собрали идеи и пожелания из трех источников: наши партнеры, наши сотрудники и руководство. Только больших модулей набралось 18 штук. По нашим предварительным оценкам, разрабатывать их пришлось бы как минимум год (а сейчас мы понимаем, что получилось бы сильно дольше). Тогда мы придумали метод оценки, позволивший нам принять решение, что мы делаем, а что откладываем «на потом».

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

Если мы сделаем это, увеличит ли это наши продажи? 0 — скорее всего нет, 1 — вряд ли, но может быть, 2 — скорее да, 3 — безусловно да.

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

Как быстро мы сможем это сделать? 0 — несколько месяцев, 1 — месяц-два, 2 — три-четыре недели, 3 — до двух недель.

Вот фрагмент этой таблицы:


 

В итоге, по сумме баллов из восемнадцати пунктов мы выбрали восемь, получивших наибольшие баллы, после обсуждений выбросили еще три и получили пять, которые и начали разрабатывать. Вот они: новые модули «Минимагазин», «Корзина удаленных объектов», «Личный кабинет», полная переделка модуля «Поиск по сайту», платформа для встраивания виджетов сторонних сервисов. Сейчас уже можно сказать, что из них лишь один пункт не в полной мере оправдал наших ожиданий (это модуль «Корзина», который оказался не таким востребованным, как мы считали). А из оставшихся тринадцати задач две мы выпустили в следующей версии 4.6, две реализуем в ближайшее время, а оставшиеся девять решили пока не делать, т.к. по здравом размышлении они не так актуальны, как некоторые задачи, появившиеся в последнее время.

А что было бы, если бы наш штат позволил нам тогда реализовать все восемнадцать пунктов? Половина нашего времени ушла бы на то, что в итоге оказалось бесполезным, а может быть даже вредным, усложняя управление продуктом. Мы получили бы чуть больше полезного, потратив гораздо больше денег. А все новые задачи становились бы в длинную очередь.

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

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

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

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

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

Тезис «Не создавайте спецификации»

В позапрошлом году я составил доклад под названием «Техническое задание — краеугольный камень проекта» и прочитал его в нескольких городах. Основная мысль доклада: пишите как можно более подробное техническое задание, согласуйте его со всеми заинтересованными лицами и в дальнейшем ни на шаг от него не отходите.

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

После прочтения главы GR про спецификации я решил провести ретроспективу нескольких недавно написанных технических заданий на тему того, насколько они оказались востребованы. Выяснилось, что 37signals совершенно правы: почти все то время, что я тратил на составление ТЗ, списков функциональных элементов, блок-схем и схем данных, оказалось потраченным впустую, потому что ими в реальности никто не пользовался. Последний пример — техническое задание на модуль поиска, где я подробно описал схему работы, структуру данных, интерфейсы взаимодействия с другими модулями. Я делал это с особой тщательностью, т.к. модуль писал удаленный разработчик. В итоге ему пригодились только те части, где описывался интерфейс управления модулем, то есть экраны настроек и вывода результатов. Все остальные главы он просмотрел, но сделал по-своему; главу про структуру базы данных он даже не читал. То есть процентов 80 документа можно было сократить, написав общими словами, что модуль должен был делать, а также нарисовав прототипы экранов.

С тех пор мы подробно пишем крайне мало документов, кроме случаев, когда это действительно нужно (к примеру, при описании API). Гораздо эффективнее просто нарисовать то, что должно получиться, и кратко написать (а может быть, даже рассказать) свое видение того, как это все должно работать. Глобальные оценки делать пока еще рано, но промежуточные итоги говорят о том, что качество хуже не стало. А время освободилось.

Говоря о спецификациях, нельзя не сказать о проблеме роста. Практически все известные мне проектировщики и разработчики считают хорошим тоном заложить рост в архитектуру продукта, чтобы он не упал и не стал неудобным, когда им будут пользоваться не десятки, а сотни тысяч пользователей или когда количество хранимых объектов будет исчисляться миллионами документов. Авторы Getting Real советуют забыть про это до тех пор, пока это не случится. Эта проблема — приятная проблема, но большинство компаний никогда не достигает такого серьезного роста. Зачем тратить время на то, что не пригодится? А если все же пригодится — ну вот тогда и надо об этом думать.

Мы стараемся не отвлекаться на такие вещи, лишь держа в голове, как примерно мы будем действовать, когда такая ситуация произойдет. Если у нас появится пользователь, которому по этим причинам наш продукт не подойдет, мы посоветуем ему другой продукт. Или дадим совет его разработчикам, как «допилить» наш продукт под его задачи (так уже не раз было). А если поток таких обращений будет ощутим — вот тогда мы займемся этой проблемой вплотную.

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

Что у нас не получилось

Тезис «Не нужно никаких бета-версий. Версия должна быть одной». В нашем случае без версионности обойтись сложно, поскольку мы производим не сервис, а stand-alone продукт. Мы не можем заставлять пользователей обновлять свои копии, поэтому версионность необходимо поддерживать. Что до беты — наиболее значимые релизы мы отдаем на тестирование нашим студиям-партнерам, именно в статусе бета-версии. В нашем случае версионность имеет еще одно преимущество: маркетинговое. Выпуская фичи и модули по мере создания (что совершенно правильно с точки зрения развития продукта) мы лишаемся возможности собрать несколько больших изменений в одну кучу, присвоить этому всему круглый номер версии и разослать об этом пресс-релиз, на который обратят гораздо больше внимание. С этим приходится считаться.

Тезис «Сделайте что-нибудь, и идите быстро». Это совершенно верный принцип для стартапов: сделал новую фичу — включил в релиз/проект. Но у нас перейти на такой цикл разработки полностью пока не получилось. Часть причин объективная: мы не стартап, продукт достаточно большой, с долгой историей. А субъективная причина заключается в том, что и мы, и наши партнеры привыкли к определеному циклу разработки. Ломать себя очень сложно.

Тезис «Сделайте выбор. Откажитесь от настроек». Программисты любят настройки, а пользователи любят профили (группы предустановленных настроек). Разрабатывая, к примеру, компонент «Новости», программист захочет ввести настройки «выводить ли анонс», «показывать ли постраничный листинг», «ссылку в полный текст ставить на заголовке или слове «подробнее». Пользователю же удобнее выбрать из профилей: полный или краткий. И прав именно пользователь. Мы пока не сумели победить настройки — мы считаем наш продукт очень гибким и не хотим лишать его этого свойства. Мы лишь в прошлом году внедрили в систему понятие «шаблоны компонентов», которое отчасти решает эту проблему. Так что в этом аспекте мы еще на полпути.

Тезис «Не разделяйте разработку и поддержку». Отрыв разработчиков от реальности — плохо. Когда ты из разработчика сайта переквалифицировался в разработчика CMS, ты перестаешь мыслить так, как те, для кого ты делаешь продукт. Совмещение разработки и поддержки помогает нивелировать недостатки этой трансформации. С другой стороны, общение в поддержке заставляет программиста часто переключаться, рвет его ритм, создает дискомфорт. Поэтому мы все же стараемся отделять разработку и поддержку. С другой стороны, мы не возражаем, если кто-то из наших сотрудников подрабатывает созданием сайтов (не в ущерб работе, разумеется).

Тезис «Скажите «нет» пользователям».... когда они просят о нововведениях. В теории это правильно. Если мы делаем какой-то продукт, мы должны лучше остальных знать, каким он должен быть, иначе мы просто не сможем сделать его инновационным и лучшим. Пользователи (и партнеры) хотят решить свои текущие потребности, а мы должны делать то, что будет актуально в будущем (еще лучше, если мы не угадываем тренды, а создаем их — Apple не даст соврать). В нашем же случае мы слишком сильно зависим от удовлетворенности наших партнеров (продажи через веб-студии и фрилансеров составляют больше 90% нашего оборота), чтобы методично игнорировать их повседневные требования. Поэтому часто нам приходится лавировать между своими взглядами и видением партнеров.

Тезис «Создайте продукт, не требующий обучения». И снова в теории это замечательно, но для нас (система управления сайтами) — сложно реализуемо. Онлайн-конструкторы сайтов должны к этому стремиться, ведь они ориентированы на конечных пользователей, но продукты нашего класса предназначаются для разработчиков. Без изучения документации, видеоуроков, консультаций со службой поддержки разработчик сможет сделать только шаблонный проект, не использовав возможности, которые дает ему API системы.

Заключение

Мы воспринимаем GR не как интересную игрушку или очередную новомодную практику управления. 12 лет жизни — серьезный срок, за это время компании либо вырастают в большие корпорации, либо умирают, либо стагнируют. Причиной стагнации, как правило, является нежелание или неумение руководства менять привычные принципы работы, подстраиваться под изменяющийся рынок. Рутинная работа, пухлые документы, длинные проекты этому очень хорошо способствуют. GR помогает в первую очередь избавиться от лишнего и второстепенного, не терять интерес к своему проекту, не останавливаться в личном и профессиональном развитии.

Говоря о прошедшем годе: я не могу сказать, на сколько процентов выросла эффективность работы или какое количество человеко-часов мы сэкономили после внедрения GR. Основной эффект — на уровне ощущений. Например:

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

- мы перестали навязывать сотрудникам или подрядчикам свое видение процесса их работы; если профессионального доверия нет, то лучше вообще не сотрудничать;

- нас стало гораздо меньше заботить то, как мы выглядим со стороны — важнее то, как мы видим себя сами;

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

- при проектировании КПД резко вырос, появилось время на самообразование и исследования.

Так что наш опыт внедрения подхода Getting Real – безусловно положительный. Надеюсь, я вас заинтересовал, и вы захотите попробовать GR сами.

условия копирования

Дорогой HR-Journal, потрудись сообщать мне о новых статьях ;)

Комментарии

Новые обсуждения

03.12 00:59 publicmd
Подарок шефу на Новый Год (7)

30.11 20:52 Raket
Анкета при приеме на работу (1)

30.11 18:49 EKG1987
Помощь новичку (0)

28.11 17:46 Степан
помощь новичку (7)

Все

Комментарии

Ваш баннер на этом месте