Вторая, заключительная часть статьи про опыт внедрения подхода Getting Real от компании 37signals на примере нашей компании. Начало опубликовано вчера.
Один из недостатков небольшого размера компании — невозможность быстро выполнить большой объем работы. Например, если мы готовим новую версию продукта, в которую должны войти большое количество глобальных изменений, с большой командой мы можем сделать это гораздо быстрее, чем с маленькой. А если мы маленькие, то выход продукта задержится, конкуренты выпустят аналоги наших нововведений быстрее, часть партнеров, устав ждать, уйдут к конкурентам.
На самом деле, по аналогии с известной поговоркой «пиво по утрам не только вредно, но и полезно», ограниченность размера помогает. Не имея возможности сделать все, что хочется, мы вынуждены как-то выкручиваться. Разбивать задачи на мелкие куски, оставлять на потом менее важную работу, искать способы достичь цели быстрее и лучше. Это помогает ощутимо увеличить эффективность работы и КПД.
Когда мы принимали решение о составе версии 4.5, мы собрали идеи и пожелания из трех источников: наши партнеры, наши сотрудники и руководство. Только больших модулей набралось 18 штук. По нашим предварительным оценкам, разрабатывать их пришлось бы как минимум год (а сейчас мы понимаем, что получилось бы сильно дольше). Тогда мы придумали метод оценки, позволивший нам принять решение, что мы делаем, а что откладываем «на потом».
Метод очень прост и антинаучен. Мы сформулировали три критерия, по которым будем оценивать каждую задачу, и каждой задаче проставили баллы от нуля до трех. Вот эти критерии:
В итоге по сумме баллов из восемнадцати пунктов мы выбрали восемь, получивших наибольшие баллы, после обсуждений выбросили еще три и получили пять, которые и начали разрабатывать. Вот они: новые модули «Минимагазин», «Корзина удаленных объектов», «Личный кабинет», полная переделка модуля «Поиск по сайту», платформа для встраивания виджетов сторонних сервисов. Сейчас уже можно сказать, что из них лишь один пункт не в полной мере оправдал наших ожиданий (это модуль «Корзина», который оказался не таким востребованным, как мы считали). А из оставшихся тринадцати задач две мы выпустили в следующей версии 4.6, две реализуем в ближайшее время, а оставшиеся девять решили пока не делать, т.к. по здравом размышлении они не так актуальны, как некоторые задачи, появившиеся в последнее время.
А что было бы, если бы мы наш штат позволил нам тогда реализовать все восемнадцать пунктов? Половина нашего времени ушла бы на то, что в итоге оказалось бесполезным, а может быть даже вредным, усложняя управление продуктом. Мы получили бы чуть больше полезного, потратив гораздо больше денег. А все новые задачи становились бы в длинную очередь.
Как я писал выше, небольшой размер компании помогает сотрудникам профессионально развиваться. Ограничения этому способствуют не в меньшей степени. В начале этого года перед нами встала необходимость разработки интерфейса для одного побочного продукта, который мы раcсчитываем выпустить в следующем году. Эта задача не из самых срочных, времени было достаточно. Мы могли взять в штат профессионального проектировщика интерфейсов, но мы не умеем оценивать профессионализм таких специалистов. Мы могли заказать эту работу специализированной компании, но их расценки весьма кусаются.
Тогда человек, занимающийся разработкой технических заданий и имеющий опыт проектирования, начал изучать принципы проектирования интерфейсов. Прочитал несколько книг и статей и начал работу. Интерфейс переделывался и корректировался несколько раз, и даже сейчас в него вносятся изменения, но мы получили то, что хотели, а сотрудник получил профессиональный навык. Конечно, можно сказать, что пара книг не сделают из человека профессионала, и он никак не сравнится со специалистом, который годами занимается этим вопросом. Это так, мы рисковали получить плохой результат, сэкономив на опыте. Но в нашем случае промежуточные этапы мы отдаем на аудит одной из ведущих российских компаний в области проектирования интерфейсов, которая исправляет наши ошибки.
И теперь мы гораздо лучше разбираемся в проектировании интерфейсов и следующая подобная задача пройдет легче.
Ограничения также помогают качеству нашей работы. Наш основной конкурент на рынке, компания большего, чем мы, размера, помимо системы управления сайтами выпускает еще несколько типов продуктов. Поскольку и запуск, и сопровождение нового продукта требует больших вложений, мы не стали повторять шаги конкурента, сосредоточившись на развитии основного продукта, ведь нам не остается ничего другого. «Узкий» продукт контролировать гораздо легче, и на этапе проектирования, и на этапе продаж, и в поддержке.
Само собой разумеется, что ограничения не подразумевают только преимущества. Если денег или рабочих рук или маркетинговых инструментов больше, это в общем случае лучше. Увеличение прибыли — наша основная цель, как и у любой коммерческой компании. У нас довольно часто возникают ситуации, когда в силу ограниченности ресурсов мы не можем позволить себе сделать то, что нам хочется: быстро запустить большой функционал, проспонсировать интересную конференцию, заказать большую рекламную кампанию. Мы стараемся подходить к этому вопросу философски. Если очень надо — можно немного поднапрячься и найти деньги в разумных размерах. А если не получается — что ж, в следующий раз получится, а пока мы учимся более эффективно управлять доступными нам ресурсами.
В позапрошлом году я составил доклад под названием «Техническое задание — краеугольный камень проекта» и прочитал его в нескольких городах. Основная мысль доклада: пишите как можно более подробное техническое задание, согласуйте его со всеми заинтересованными лицами и в дальнейшем ни на шаг от него не отходите.
Сейчас я уже не уверен так в правильности такого подхода. По крайней мере, для внутренних проектов (тех, которые создаются для себя, а не для стороннего заказчика) это совершенно точно не так.
После прочтения главы GR про спецификации я решил провести ретроспективу нескольких недавно написанных технических заданий на тему того, насколько они оказались востребованы. Выяснилось, что 37signals совершенно правы: почти все то время, что я тратил на составление ТЗ, списков функциональных элементов, блок-схем и схем данных, оказалось потраченным впустую, потому что ими в реальности никто не пользовался. Последний пример — техническое задание на модуль поиска, где я подробно описал схему работы, структуру данных, интерфейсы взаимодействия с другими модулями. Я делал это с особой тщательностью, т.к. модуль писал удаленный разработчик. В итоге ему пригодились только те части, где описывался интерфейс управления модулем, то есть экраны настроек и вывода результатов. Все остальные главы он просмотрел, но сделал по-своему; главу про структуру базы данных он даже не читал. То есть процентов 80 документа можно было сократить, написав общими словами, что модуль должен был делать, а также нарисовав прототипы экранов.
С тех пор мы подробно пишем крайне мало документов, кроме случаев, когда это действительно нужно, к примеру, описание API. Гораздо эффективнее просто нарисовать то, что должно получиться, и кратко написать (а может быть даже рассказать) свое видение того, как это все должно работать. Глобальные оценки делать пока еще рано, но промежуточные итоги говорят о том, что качество хуже не стало. А время освободилось.
Говоря о спецификациях, нельзя не сказать о проблеме роста. Практически все известные мне проектировщики и разработчики считают хорошим тоном заложить рост в архитектуру продукта, чтобы он не упал и не стал неудобным, когда им будут пользоваться не десятки, а сотни тысяч пользователей или когда количество хранимых объектов будет исчисляться миллионами документов. Авторы Getting Real советуют забыть про это до тех пор, пока это не случится. Эта проблема — приятная проблема, но большинство компаний никогда не достигает такого серьезного роста. Зачем тратить время на то, что не пригодится? А если все же пригодится — ну вот тогда и надо об этом думать.
Мы стараемся не отвлекаться на такие вещи, лишь держа в голове, как примерно мы будем действовать, когда такая ситуация произойдет. Если у нас появится пользователь, которому по этим причинам наш продукт не подойдет, мы посоветуем ему другой продукт. Или дадим совет его разработчикам, как «допилить» наш продукт под его задачи (так уже не раз было). А если поток таких обращений будет ощутим — вот тогда мы займемся этой проблемой вплотную.
И наконец финальный тезис GR о спецификациях: забудьте о мелочах. Какие конкретно пункты будут в настройках данного экрана, какое расстояние будет между превью изображений, по скольку строк в списке показывать данные — об этом не нужно думать до того времени, как такой вопрос реально встанет. Как показывает наша собственная, пусть и не очень продолжительная практика следования этому совету, это действительно так. На живом проекте, пусть даже полуфабрикате, принимать решения гораздо проще и правильнее, чем на этапе проектирования.
«Не нужно никаких бета-версий. Версия должна быть одной». В нашем случае без версионности обойтись сложно, поскольку мы производим не сервис, а standalone-продукт. Мы не можем заставлять пользователей обновлять свои копии, поэтому версионность необходимо поддерживать. Что до беты — наиболее значимые релизы мы отдаем на тестирование нашим студиям-партнерам, именно в статусе бета-версии. В нашем случае версионность имеет еще одно преимущество: маркетинговое. Выпуская фичи и модули по мере создания (что совершенно правильно с точки зрения развития продукта) мы лишаемся возможности собрать несколько больших изменений в одну кучу, присвоить этому всему круглый номер версии и разослать об этом пресс-релиз, на который обратят гораздо больше внимание. С этим приходится считаться.
«Сделайте что-нибудь и идите быстро». Это совершенно верный принцип для стартапов: сделал новую фичу — включил в релиз/проект. Но у нас перейти на такой цикл разработки полностью пока не получилось. Часть причин объективная: мы не стартап, продукт достаточно большой, с долгой историей. А субъективная причина заключается в том, что и мы, и наши партнеры привыкли к определеному циклу разработки. Ломать себя очень сложно.
«Сделайте выбор. Откажитесь от настроек». Программисты любят настройки, а пользователи любят профили (группы предустановленных настроек). Разрабатывая, к примеру, компонент «Новости», программист захочет ввести настройки «выводить ли анонс», «показывать ли постраничный листинг», «ссылку в полный текст ставить на заголовке или слове «подробнее». Пользователю же удобнее выбрать из профилей: полный или краткий. И прав именно пользователь. Мы пока не сумели победить настройки — мы считаем наш продукт очень гибким и не хотим лишать его этого свойства. Мы лишь в прошлом году внедрили в систему понятие «шаблоны компонентов», которое отчасти решает эту проблему. Так что в этом аспекте мы еще на полпути.
«Не разделяйте разработку и поддержку». Отрыв от реальности разработчиков — плохо. Когда ты из разработчика сайта переквалифицировался в разработчика CMS, ты перестаешь мыслить так, как те, для кого ты делаешь продукт. Совмещение разработки и поддержки помогает нивелировать недостатки этой трансформации. С другой стороны, общение в поддержке заставляет программиста часто переключаться, рвет его ритм, создает дискомфорт. Поэтому мы все же стараемся отделять разработку и поддержку. С другой стороны, мы не возражаем, если кто-то из наших сотрудников подрабатывает созданием сайтов (не в ущерб работе, разумеется).
«Скажите «нет» пользователям».… когда они просят о нововведениях. В теории это правильно. Если мы делаем какой-то продукт, мы должны лучше остальных знать, каким он должен быть, иначе мы просто не сможем сделать его инновационным и лучшим. Пользователи (и партнеры) хотят решить свои текущие потребности, а мы должны делать то, что будет актуально в будущем (еще лучше, если мы не угадываем тренды, а создаем их — Apple не даст соврать). В нашем же случае мы слишком сильно зависим от удовлетворенности наших партнеров (продажи через веб-студии и фрилансеров составляют больше 90% нашего оборота), чтобы методично игнорировать их повседневные требования. Поэтому часто нам приходится лавировать между своими взглядами и видением партнеров.
«Создайте продукт, не требующий обучения». И снова в теории это замечательно, но для нас (система управления сайтами) — сложно реализуемо. Онлайн-конструкторы сайтов должны к этому стремиться, ведь они ориентированы на конечных пользователей, но продукты нашего класса предназначаются для разработчиков. Без изучения документации, видеоуроков, консультаций со службой поддержки разработчик сможет сделать только шаблонный проект, не использовав возможности, которые дает ему API системы.
Мы воспринимаем GR не как интересную игрушку или очередную новомодную практику управления. 12 лет жизни — серьезный срок, за это время компании либо вырастают в большие корпорации, либо умирают, либо стагнируют. Причиной стагнации как правило является нежелание или неумение руководства менять привычные принципы работы, подстраиваться под изменяющийся рынок. Рутинная работа, пухлые документы, длинные проекты этому очень хорошо способствуют. GR помогает в первую очередь избавиться от лишнего и второстепенного, не терять интерес к своему проекту, не останавливаться в личном и профессиональном развитии.
Говоря о прошедшем годе: я не могу сказать, на сколько процентов выросла эффективность работы или какое количество человеко-часов мы сэкономили после внедрения GR. Основной эффект — на уровне ощущений. Например:
Ограничения помогают
Один из недостатков небольшого размера компании — невозможность быстро выполнить большой объем работы. Например, если мы готовим новую версию продукта, в которую должны войти большое количество глобальных изменений, с большой командой мы можем сделать это гораздо быстрее, чем с маленькой. А если мы маленькие, то выход продукта задержится, конкуренты выпустят аналоги наших нововведений быстрее, часть партнеров, устав ждать, уйдут к конкурентам.
На самом деле, по аналогии с известной поговоркой «пиво по утрам не только вредно, но и полезно», ограниченность размера помогает. Не имея возможности сделать все, что хочется, мы вынуждены как-то выкручиваться. Разбивать задачи на мелкие куски, оставлять на потом менее важную работу, искать способы достичь цели быстрее и лучше. Это помогает ощутимо увеличить эффективность работы и КПД.
Когда мы принимали решение о составе версии 4.5, мы собрали идеи и пожелания из трех источников: наши партнеры, наши сотрудники и руководство. Только больших модулей набралось 18 штук. По нашим предварительным оценкам, разрабатывать их пришлось бы как минимум год (а сейчас мы понимаем, что получилось бы сильно дольше). Тогда мы придумали метод оценки, позволивший нам принять решение, что мы делаем, а что откладываем «на потом».
Метод очень прост и антинаучен. Мы сформулировали три критерия, по которым будем оценивать каждую задачу, и каждой задаче проставили баллы от нуля до трех. Вот эти критерии:
- Если мы сделаем это, увеличит ли это наши продажи? 0 — скорее всего нет, 1 — вряд ли, но может быть, 2 — скорее да, 3 — безусловно да.
- Насколько значимый получится из этого информационный повод, сможем ли мы наличием этого функционала заинтересовать потенциальных партнеров и обозревателей?
- Как быстро мы сможем это сделать? 0 — несколько месяцев, 1 — месяц-два, 2 — три-четыре недели, 3 — до двух недель.
| Функционал | Деньги | Инфоповод | Скорость | Итого |
|---|---|---|---|---|
| Новый модуль поиска | 2 | 1 | 0 | 3 |
| Модуль «Минимагазин» | 3 | 2 | 1 | 6 |
| Модуль «Личный кабинет» | 2 | 2 | 1 | 5 |
| Платформа встраивания виджетов | 2 | 2 | 1 | 5 |
| Изменения в модуле «Облако тэгов» | 0 | 0 | 2 | 2 |
| Переделка модуля «Интернет-магазин» | 3 | 3 | 0 | 6 |
А что было бы, если бы мы наш штат позволил нам тогда реализовать все восемнадцать пунктов? Половина нашего времени ушла бы на то, что в итоге оказалось бесполезным, а может быть даже вредным, усложняя управление продуктом. Мы получили бы чуть больше полезного, потратив гораздо больше денег. А все новые задачи становились бы в длинную очередь.
Как я писал выше, небольшой размер компании помогает сотрудникам профессионально развиваться. Ограничения этому способствуют не в меньшей степени. В начале этого года перед нами встала необходимость разработки интерфейса для одного побочного продукта, который мы раcсчитываем выпустить в следующем году. Эта задача не из самых срочных, времени было достаточно. Мы могли взять в штат профессионального проектировщика интерфейсов, но мы не умеем оценивать профессионализм таких специалистов. Мы могли заказать эту работу специализированной компании, но их расценки весьма кусаются.
Тогда человек, занимающийся разработкой технических заданий и имеющий опыт проектирования, начал изучать принципы проектирования интерфейсов. Прочитал несколько книг и статей и начал работу. Интерфейс переделывался и корректировался несколько раз, и даже сейчас в него вносятся изменения, но мы получили то, что хотели, а сотрудник получил профессиональный навык. Конечно, можно сказать, что пара книг не сделают из человека профессионала, и он никак не сравнится со специалистом, который годами занимается этим вопросом. Это так, мы рисковали получить плохой результат, сэкономив на опыте. Но в нашем случае промежуточные этапы мы отдаем на аудит одной из ведущих российских компаний в области проектирования интерфейсов, которая исправляет наши ошибки.
И теперь мы гораздо лучше разбираемся в проектировании интерфейсов и следующая подобная задача пройдет легче.
Ограничения также помогают качеству нашей работы. Наш основной конкурент на рынке, компания большего, чем мы, размера, помимо системы управления сайтами выпускает еще несколько типов продуктов. Поскольку и запуск, и сопровождение нового продукта требует больших вложений, мы не стали повторять шаги конкурента, сосредоточившись на развитии основного продукта, ведь нам не остается ничего другого. «Узкий» продукт контролировать гораздо легче, и на этапе проектирования, и на этапе продаж, и в поддержке.
Само собой разумеется, что ограничения не подразумевают только преимущества. Если денег или рабочих рук или маркетинговых инструментов больше, это в общем случае лучше. Увеличение прибыли — наша основная цель, как и у любой коммерческой компании. У нас довольно часто возникают ситуации, когда в силу ограниченности ресурсов мы не можем позволить себе сделать то, что нам хочется: быстро запустить большой функционал, проспонсировать интересную конференцию, заказать большую рекламную кампанию. Мы стараемся подходить к этому вопросу философски. Если очень надо — можно немного поднапрячься и найти деньги в разумных размерах. А если не получается — что ж, в следующий раз получится, а пока мы учимся более эффективно управлять доступными нам ресурсами.
Не создавайте спецификации
В позапрошлом году я составил доклад под названием «Техническое задание — краеугольный камень проекта» и прочитал его в нескольких городах. Основная мысль доклада: пишите как можно более подробное техническое задание, согласуйте его со всеми заинтересованными лицами и в дальнейшем ни на шаг от него не отходите.
Сейчас я уже не уверен так в правильности такого подхода. По крайней мере, для внутренних проектов (тех, которые создаются для себя, а не для стороннего заказчика) это совершенно точно не так.
После прочтения главы GR про спецификации я решил провести ретроспективу нескольких недавно написанных технических заданий на тему того, насколько они оказались востребованы. Выяснилось, что 37signals совершенно правы: почти все то время, что я тратил на составление ТЗ, списков функциональных элементов, блок-схем и схем данных, оказалось потраченным впустую, потому что ими в реальности никто не пользовался. Последний пример — техническое задание на модуль поиска, где я подробно описал схему работы, структуру данных, интерфейсы взаимодействия с другими модулями. Я делал это с особой тщательностью, т.к. модуль писал удаленный разработчик. В итоге ему пригодились только те части, где описывался интерфейс управления модулем, то есть экраны настроек и вывода результатов. Все остальные главы он просмотрел, но сделал по-своему; главу про структуру базы данных он даже не читал. То есть процентов 80 документа можно было сократить, написав общими словами, что модуль должен был делать, а также нарисовав прототипы экранов.
С тех пор мы подробно пишем крайне мало документов, кроме случаев, когда это действительно нужно, к примеру, описание API. Гораздо эффективнее просто нарисовать то, что должно получиться, и кратко написать (а может быть даже рассказать) свое видение того, как это все должно работать. Глобальные оценки делать пока еще рано, но промежуточные итоги говорят о том, что качество хуже не стало. А время освободилось.
Говоря о спецификациях, нельзя не сказать о проблеме роста. Практически все известные мне проектировщики и разработчики считают хорошим тоном заложить рост в архитектуру продукта, чтобы он не упал и не стал неудобным, когда им будут пользоваться не десятки, а сотни тысяч пользователей или когда количество хранимых объектов будет исчисляться миллионами документов. Авторы Getting Real советуют забыть про это до тех пор, пока это не случится. Эта проблема — приятная проблема, но большинство компаний никогда не достигает такого серьезного роста. Зачем тратить время на то, что не пригодится? А если все же пригодится — ну вот тогда и надо об этом думать.
Мы стараемся не отвлекаться на такие вещи, лишь держа в голове, как примерно мы будем действовать, когда такая ситуация произойдет. Если у нас появится пользователь, которому по этим причинам наш продукт не подойдет, мы посоветуем ему другой продукт. Или дадим совет его разработчикам, как «допилить» наш продукт под его задачи (так уже не раз было). А если поток таких обращений будет ощутим — вот тогда мы займемся этой проблемой вплотную.
И наконец финальный тезис GR о спецификациях: забудьте о мелочах. Какие конкретно пункты будут в настройках данного экрана, какое расстояние будет между превью изображений, по скольку строк в списке показывать данные — об этом не нужно думать до того времени, как такой вопрос реально встанет. Как показывает наша собственная, пусть и не очень продолжительная практика следования этому совету, это действительно так. На живом проекте, пусть даже полуфабрикате, принимать решения гораздо проще и правильнее, чем на этапе проектирования.
Что у нас не получилось
«Не нужно никаких бета-версий. Версия должна быть одной». В нашем случае без версионности обойтись сложно, поскольку мы производим не сервис, а standalone-продукт. Мы не можем заставлять пользователей обновлять свои копии, поэтому версионность необходимо поддерживать. Что до беты — наиболее значимые релизы мы отдаем на тестирование нашим студиям-партнерам, именно в статусе бета-версии. В нашем случае версионность имеет еще одно преимущество: маркетинговое. Выпуская фичи и модули по мере создания (что совершенно правильно с точки зрения развития продукта) мы лишаемся возможности собрать несколько больших изменений в одну кучу, присвоить этому всему круглый номер версии и разослать об этом пресс-релиз, на который обратят гораздо больше внимание. С этим приходится считаться.
«Сделайте что-нибудь и идите быстро». Это совершенно верный принцип для стартапов: сделал новую фичу — включил в релиз/проект. Но у нас перейти на такой цикл разработки полностью пока не получилось. Часть причин объективная: мы не стартап, продукт достаточно большой, с долгой историей. А субъективная причина заключается в том, что и мы, и наши партнеры привыкли к определеному циклу разработки. Ломать себя очень сложно.
«Сделайте выбор. Откажитесь от настроек». Программисты любят настройки, а пользователи любят профили (группы предустановленных настроек). Разрабатывая, к примеру, компонент «Новости», программист захочет ввести настройки «выводить ли анонс», «показывать ли постраничный листинг», «ссылку в полный текст ставить на заголовке или слове «подробнее». Пользователю же удобнее выбрать из профилей: полный или краткий. И прав именно пользователь. Мы пока не сумели победить настройки — мы считаем наш продукт очень гибким и не хотим лишать его этого свойства. Мы лишь в прошлом году внедрили в систему понятие «шаблоны компонентов», которое отчасти решает эту проблему. Так что в этом аспекте мы еще на полпути.
«Не разделяйте разработку и поддержку». Отрыв от реальности разработчиков — плохо. Когда ты из разработчика сайта переквалифицировался в разработчика CMS, ты перестаешь мыслить так, как те, для кого ты делаешь продукт. Совмещение разработки и поддержки помогает нивелировать недостатки этой трансформации. С другой стороны, общение в поддержке заставляет программиста часто переключаться, рвет его ритм, создает дискомфорт. Поэтому мы все же стараемся отделять разработку и поддержку. С другой стороны, мы не возражаем, если кто-то из наших сотрудников подрабатывает созданием сайтов (не в ущерб работе, разумеется).
«Скажите «нет» пользователям».… когда они просят о нововведениях. В теории это правильно. Если мы делаем какой-то продукт, мы должны лучше остальных знать, каким он должен быть, иначе мы просто не сможем сделать его инновационным и лучшим. Пользователи (и партнеры) хотят решить свои текущие потребности, а мы должны делать то, что будет актуально в будущем (еще лучше, если мы не угадываем тренды, а создаем их — Apple не даст соврать). В нашем же случае мы слишком сильно зависим от удовлетворенности наших партнеров (продажи через веб-студии и фрилансеров составляют больше 90% нашего оборота), чтобы методично игнорировать их повседневные требования. Поэтому часто нам приходится лавировать между своими взглядами и видением партнеров.
«Создайте продукт, не требующий обучения». И снова в теории это замечательно, но для нас (система управления сайтами) — сложно реализуемо. Онлайн-конструкторы сайтов должны к этому стремиться, ведь они ориентированы на конечных пользователей, но продукты нашего класса предназначаются для разработчиков. Без изучения документации, видеоуроков, консультаций со службой поддержки разработчик сможет сделать только шаблонный проект, не использовав возможности, которые дает ему API системы.
Заключение
Мы воспринимаем GR не как интересную игрушку или очередную новомодную практику управления. 12 лет жизни — серьезный срок, за это время компании либо вырастают в большие корпорации, либо умирают, либо стагнируют. Причиной стагнации как правило является нежелание или неумение руководства менять привычные принципы работы, подстраиваться под изменяющийся рынок. Рутинная работа, пухлые документы, длинные проекты этому очень хорошо способствуют. GR помогает в первую очередь избавиться от лишнего и второстепенного, не терять интерес к своему проекту, не останавливаться в личном и профессиональном развитии.
Говоря о прошедшем годе: я не могу сказать, на сколько процентов выросла эффективность работы или какое количество человеко-часов мы сэкономили после внедрения GR. Основной эффект — на уровне ощущений. Например:
- мы перестали думать, что наш небольшой штат и неформализованные методы управления являются недостатками; это сильно влияет на самовосприятие и собственную мотивацию, убирает ложные цели
- мы перестали навязывать сотрудникам или подрядчикам свое видение процесса их работы; если профессионального доверия нет, то лучше вообще не сотрудничать
- нас стало гораздо меньше заботить то, как мы выглядим со стороны — важнее то, как мы видим себя сами
- разработка стала гораздо более управляемой; время между постановкой проблемы и ее решением сократилось в разы, а быстрый результат очень сильно вдохновляет
- при проектировании КПД резко вырос, появилось время на самообразование и исследования
