Книга Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов, страница 37. Автор книги Бен Хоровиц

Разделитель для чтения книг в онлайн библиотеке

Онлайн книга «Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов»

Cтраница 37

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

Управлять компанией по показателям – то же, что раскрашивать картину по нумерованным сегментам

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

HP стремилась обеспечить высокую прибыль сейчас и в долгосрочной перспективе. Но, сосредоточившись на краткосрочных показателях прибыли, компания пожертвовала прибылью в будущем. Заметьте, что помимо прибыли можно было бы использовать множество других показателей – как количественных, так и качественных.

• Растет или падает наша доля рынка по сравнению с долями основных конкурентов?

• Растет или падает уровень удовлетворенности потребителей?

• Что наши собственные программисты думают о наших продуктах?


Управляя организацией так, будто бы она была «черным ящиком», некоторые подразделения HP оптимизировали текущие показатели прибыли за счет снижения своей конкурентоспособности в будущем. В свою очередь, компания поощряла менеджеров за достижение заданных показателей прибыли в краткосрочном аспекте, что обернулось большими потерями в долгосрочном. Лучше было бы ориентироваться на «белый ящик». Это означает, что необходимо учитывать не только динамику финансовых показателей, но и то, каким образом они достигаются. Следует штрафовать менеджеров, жертвующих будущим компании ради сиюминутных прибылей, и поощрять тех, кто инвестирует в перспективу, даже если отдачу от таких инвестиций пока трудно оценить.

Несколько слов в заключение

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

Управленческий долг

Благодаря автору технологии wiki [24] программисту Уорду Каннингему понятие «технический долг» получило широкое распространение. Если вы, экономя время, быстро пишете «грязный» код со многими ошибками, то в итоге вам придется вернуть это время назад с процентами. Иногда подобные компромиссы оправданны, но если вы станете прибегать к ним постоянно, то столкнетесь с серьезными неприятностями. Существует еще одна похожая, но менее понятная концепция, которую я назову управленческим долгом.

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

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

1. Двое на одном стуле.

2. Повышение зарплаты ключевому сотруднику, получившему предложение от другой компании.

3. Отсутствие системы управления деятельностью или оценки труда сотрудников.

Двое на одном стуле

Как вы поступаете, если у вас есть два одинаково блестящих сотрудника, идеально подходящих на одну и ту же должность в организационной структуре? Допустим, один из них – разработчик архитектуры компьютерной системы мирового уровня, отлично руководящий группой программистов, но не имеющий опыта в выведении компании на следующий уровень развития. Другой – выдающийся операционный директор, который не слишком силен в технических вопросах. Вы бы хотели сохранить для компании обоих, но вакансия только одна. У вас появляется блестящая идея посадить обоих на один стул и взять небольшой управленческий долг. Краткосрочные выгоды очевидны: вы сохраняете обоих сотрудников; никого из них не надо специально обучать, поскольку теоретически они будут обучать друг друга, и вы мгновенно решите проблему с необходимыми навыками и знаниями. К сожалению, за эти преимущества придется заплатить очень дорого и с процентами.

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

Кроме того, взяв на должность сразу двух человек, вы уничтожите систему ответственности за результаты. Если сорван график работ, кто будет нести ответственность? Если операционный директор отвечает за соблюдение графика, а директор по техническим вопросам – за производительность программного приложения, то все понятно. Но если операционный директор вынуждает программистов соблюдать график работ даже ценой срыва технического задания по производительности продукта, то кто будет отвечать? И кто сообщит вам об этом? Хуже всего то, что со временем оба описанных негативных последствия имеют свойство усиливаться. На какое-то очень короткое время вы можете их сгладить, увеличив количество деловых встреч или попытавшись в деталях прописать сферу ответственности каждого менеджера. Однако в процессе работы эти когда-то скрупулезно выписанные разграничения сотрутся, и организация начнет постепенно деградировать. В итоге вам все равно придется выплатить немалую сумму «управленческого долга» и уволить одного из двух менеджеров, или ваша высокотехнологичная компания придет в упадок.

Вход
Поиск по сайту
Ищем:
Календарь
Навигация