Оптимизация работы 1С (комикс)

Подозреватель программ Нашел подборку фотографий мобилкой, еще с 2007 года из замечательной компании “Столица-Медикл”. На фотографиях мой тогдашний босс и коллега. Все описанное на картинках сплошной вымысел, на самом деле мужики очень профессиональные и дело свое знают лучше всех.

wpid-Page_1-2011-01-13-13-35.jpg
wpid-Page_2-2011-01-13-13-35.jpg

wpid-Page_3-2011-01-13-13-35.jpg

wpid-Page_4-2011-01-13-13-35.jpg

Коммуникации в больших и малых командах

wpid-striphandler-2.ashx-2011-01-12-19-32.gifЧем больше команда, тем больше времени надо на коммуникации. Тем дольше информация расползается по команде. Рассмотрим обычную ситуацию: компания из 2 000 сотрудников, 10 топ-менеджеров, под каждым топом 10 менеджеров среднего звена, под каждым менеджером среднего звена еще по 3 руководителя группы. Допустим, на совете топ-менеджеров приняли какое-то решение, которое касается деятельности каждого сотрудника. Решение непростое, большое, емейлом и не описать вот так. И тогда каждый топ-менеджер собирает своих сотрудников на совещание. То есть нужно провести еще 10 совещаний. Отчетные совещания проходят раз в две недели, да и если созывать внеплановое совещание, все равно раньше, чем через 2 недели, всех собрать толком и не получится. После этого каждый менеджер среднего звена на летучке отдела все сообщит, а это будет еще через неделю. В промежутках между совещаниями на разных уровнях идет активная переписка с уточнениями и вопросами касательно принятого решения.

И что же мы видим: более-менее объемная информация распространяется от руководства до младших сотрудников не менее чем за 3 недели. И это в относительно небольшой компании. Сокращение сотрудников компании до 200 человек (в 10 раз) уменьшит срок прохождения только на 1 неделю, то есть время доставки информации зависит от количества уровней иерархии. Что же делать?

Руководство никому не доверяет принятие решений
В этом случае нужно основную часть коммуникаций перенести в онлайн, например, в интранет-систему. Это позволит не отвечать на один и тот же вопрос дважды, да и не будет необходимости собирать кучу народа на совещания. Также это поможет избежать ошибок коммуникации (про которые я писал ранее). Подобным образом поступают, например, компании “большой четверки”.

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

Оба пути имеют право на существование, так что тут решать только вам, как поступить.

Все сложные вещи простые

wpid-LMqj7-2011-01-7-19-15.jpgНе бывает сложных проблем, задач, решений или систем. Но, “просто” не значит “легко”. Если вы проектируете сложную систему и сразу закладываете сложности, лучше бросайте это дело и займитесь чем-нибудь другим, все равно такая система обречена на провал. Все в нашем мире устроено просто и единственная сложность, которая есть, это многообразие вариантов и комбинаций простых вещей. Мастерство тем выше, чем меньше простых составляющих нужно для получения результата. Особенно это заметно в больших системах, где сходу нельзя определить минимальное необходимое и достаточное количество простых элементов. Касательно технологических проектов и стартапов это хорошо видно: те, которые начинали с гаража/одного сервера, сейчас имеют преимущество перед теми, которые начинали с какой-то сложной схемы.

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

Сложность системы можно определять по временной шкале: сколько времени нужно инженеру, чтобы разобраться, как работает система. Если срок приближается к году или даже больше, что-то явно не так. Либо же вы разрабатываете военный/космический проект, начатый еще 25 лет назад. Выгода определения сложности в человекоднях очевидна: сразу видны издержки на привлечение нового специалиста в проект, а также виден коэффициент, понижающий стоимость проекта при продаже. Чем больше времени надо на освоение системы, тем выше и эксплуатационные риски, и кадровые.

Жизненных примеров полно, хотя бы та же электроника, которая собирается вся на одной элементной базе.

Минимизация ошибок или бесконечное увеличение времени протекания процессов

wpid-strips_07-2010-11-19-21-27.gifИтак, в этой статье мы рассмотрим, как можно уменьшить количество ошибок в итоговом результате работы. Вообще, не стоит это все воспринимать как нечто догматическое, это просто мое субъективное мнение.

Разделим ошибки на категории:
1) ошибки коммуникации (например, разное понимание одного и того же термина приводят к искажению восприятия задачи).
2) Ошибки, допущенные непосредственным исполнителем в процессе реализации.
3) Ошибки, допущенные при проектировании и/или при постановке задачи. Или вообще на этапе придумывания идеи.

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

Ошибки коммуникации
Любое общение суть передача набора понятий от одного человека к другому человеку (или же от нескольких/к нескольким). Поскольку общение происходит посредством языка, а язык это набор абстрактных понятий, выраженных в словах. (Во, блин, как заумно завернул). Ну так вот, во время общения под одним и тем же словом каждый может понимать разные вещи. Чем больше актов общения происходит, тем больше вероятность ошибки. Более сложным случаем являются цепочки общения (например, заказчик высказывает пожелание менеджеру проектов, тот объясняет задачу дизайнеру, тот тимлидеру, а тимлидер разработчику). Как же уменьшить количество этих ошибок? Очень просто: нужно уменьшать количество актов непосредственно полезного общения, увеличивать качество общения, и после каждого акта составлять протокол, в котором каждый участник общения описывает своими словами договоренности, достигнутые в процессе общения, который затем проверяется каждым участником общения и каждый тезис либо подтверждается, либо опровергается. Таким образом, мы по сути увеличиваем количество актов общения как минимум вдвое. Но зато уменьшается количество ошибок, ведь каждый протокол скорее всего найдет хотя бы часть ошибок. С другой стороны протокол может вносить ошибки, поэтому каким-то образом нужно контролировать и протоколы. Например, на каждые N протоколов составлять большой сводный протокол, причем силами других людей, в котором бы излагались все тезисы из предыдущих протоколов. В целом, в большинстве компаний так и происходит, люди просто пишут друг другу письма со своим пониманием совещания.

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

Ошибки исполнителя
Тут причины простые: люди иногда ошибаются и такова природа. Программист может где-то неправильно реализовать логику или не учесть какую-то ситуацию. Выход простой: тестировать перед тем, как использовать в жизни. В случае с кодом ситуация особенно показательна: на сам классы пишутся юнит-тесты, затем на сам код пишутся (или проводятся руками) функциональные тесты, затем на всю систему пишутся (ну или же опять-таки руками делаются) интеграционные тесты. Однако, если проект большой, то есть вероятность, что в тестах будет ошибка, которую пропустит ошибку в коде или в классе. А значит, все тесты надо покрывать тестами и так далее, такое рекурсивное тестирование.

А это уже сильно затягивает процесс разработки и откладывает момент внедрения и эксплуатации продукта.

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

Все это тоже может очень сильно оттянуть момент начала работы.

Что делать?
Глядя на все описанное можно сделать вывод, что внесение даже сколь-нибудь малого изменения в большую систему, да еще и при условии, что разные изменения вносятся постоянно и параллельно, может затянуться на недели или даже месяцы. Выходов тут 3:

1) Радикальный экстремизм. Вообще минимизировать всякие проверки и быть готовым быстро-быстро править-чинить. По сути, выкладывать код, который банально запускается и не удаляет все данные. 😉
2) Радикальный консерватизм: следовать всем-всем процедурам проверки и выкладывать много раз проверенный код. Подход хорош, когда нет возможности быстренько починить или же когда цена ошибки очень высока.
3) Умеренный экстремизм. В общем-то, некая комбинация первого и второго вариантов. Нужно заранее спроектировать свою систему так, чтобы ни одно изменение не могло затронуть ее целиком. Тестировать на предмет соответствия требованиям и работоспособности кода, выкладывать так, чтобы сначала изменение затрагивало только часть системы и уже после опытной эксплуатации распространять изменения на всю систему.

Лично мне ближе 3-й вариант. Похожим образом действуют, например, Facebook, ВКонтакте, Бегун, Twitter и, наверняка, еще немало хороших организаций.

Кредит и депозит в проектировании и разработке

wpid-Bugs_and_Feelings-2010-10-6-01-10.jpgТакой небольшой экспресс-пост. Для людей, далеких от жизни, поясню: кредит — деньги сейчас, потом долго платить небольшими частями и много переплачивать в итоге. Депозит — сразу отдаете деньги банку, а потом каждый месяц собираете проценты. Посмотрим, какое это имеет отношение к разработке. У любой задачи есть как минимум два решения. Первое решение быстрое, костыльное, с кучей возможных ограничений для будущего развития. Второе решение более трудоемкое, но лишено основных недостатков первого. Казалось бы, второе решение панацея от головной боли, но все не так просто.

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

Как вам новые хедеры?

wpid-strips_02-2010-07-18-19-21.jpgКак вам новые картинки? Старательно отобранные в интернете, чтобы радовать ваш глаз.

Я про вас помню :-)

wpid-002hbx0s-2010-06-28-02-22.jpegЯ про вас помню, уважаемые читатели. Разрываюсь между работой, продолжением статьи про бонусы и новой статьей про PR личности внутри крупной организации. Постараюсь не разочаровать вас новым материалом, он уже на подходе. 🙂

Личностные бренды внутри компании

wpid-bunnymanagementju4-2010-06-10-15-59.jpgЭта статья посвящена влиянию пиара конкретных личностей внутри компании, созданию так называемых внутренних брендов. Как обычно, рассмотрим некий абстрактно-реальный пример.

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

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

Как же можно использовать такие бренды? Точно так же, как и любые другие, задавать мнения в коллективе, например, или же для внешнего пиара. Что характерно, польза от таких брендов может быть как руководству компании, так и рядовым сотрудникам. Рассмотрим примеры:

Пример 1. Если вы руководитель организации.

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

Пример 2. Если вы коллега человека-бренда.

Тут вы можете действовать в обратную сторону, а именно лоббировать через человека-бренда какие-либо вещи перед руководством компании. Или же можете облегчить свою работу, согласовав с Аркадием стратегию действий, а затем в случае возникновения ситуаций, когда прибегают люди из других отделов и начинают топать ножками и требовать чего-то, противоречащего стратегии, говорить: “Так, Крочко сказал делать именно так.” Или же в случае сомнений у ваших подчиненных, которые могут привести к долгим согласованиям, говорить им: “Крочко разрешил,” — если сомнительное действие будет производиться в рамках стратегии. Хорошие отношения с человеком-брендом могут сильно облегчить жизнь менеджера в компании.

Пример 3. Если вы человек-бренд.

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

Как создать бренд?

Чтобы создать бренд, руководитель должен выбрать подходящую кандидатуру. Основным критерием для отбора является максимальное значение одного (или нескольких) из показателей:

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

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

Когда-нибудь, когда руки дойдут, расскажу про каждый из случаев поподробнее. В том числе и про то, чем может быть плох личностный бренд, про конкуренцию брендов внутри одной организации, про звездную болезнь бренда. А может и еще про что-нибудь.

Неуспешный продавец

wpid-10-03-12-2010-06-8-23-501.gif
Далее под словом “товар” я подразумеваю или товар, или услугу.
Почему-то бытует мнение, что хороший продавец обязательно должен хорошо врать. Обосновывают это тем, что если он хорошо врет, то сможет впарить любой товар кому угодно. И многим нравятся такие продавцы, потому что в краткосрочной перспективе они могу заметно увеличить выручку компании.

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

1) Они не получили того результата, за которым пришли.
2) Их обманывали и втирали, что тот результат, который они получают, им и нужен.

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

Как же тогда продавать? А очень просто. Достаточно следовать следующей стратегии:

1) Поймите, что ваша компания делает лучше всего.
2) При первом контакте максимально качественно выясните, что действительно нужно клиенту.
3) Подумайте, сможет ли ваш товар удовлетворить потребность клиента лучше, чем другие товары на рынке.
4) Если на предыдущий вопрос ответили “да” — смело предлагайте ваш товар. Если ответили нет — честно говорите, что вы не специализируетесь в удовлетворении той потребности, которая в данный момент есть у клиента, и что ваш товар удовлетворяет другие потребности.

Просто? Реализуемо?

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

З. Ы. Недавно обсуждал как раз эту тему с другом, он именно так и управляет компанией. И у них все хорошо.

Как не надо назначать бонусы или закон вместо справедливости [часть 1]

wpid-1266301718_rabotnik-2010-06-7-00-401.jpgЗа время работы в E-Xecutive (относительно небольшое) я усвоил несколько хороших идей о том, как надо управлять командами. Этот пост про одну из таких идей: “По закону, а не по справедливости.”

Давайте разберемся поподробнее в этом.

Что есть закон?
Это набор правил и критериев, по которым раздаются бонусы и по которым раздаются лучи поноса. Говоря казенным языком, регламент.

Что есть справедливость?
Это личное отношение руководителя или коллектива, на основании которого могут приниматься решения. Проще говоря, управление по понятиям.

Итак, разберем несколько примеров и определим типы управления в каждом из случаев.

Пример 1.

Вот и наступил декабрь, один из сотрудников компании вспомнил, что неплохо бы онлайн-открытку сделать для клиентов и вынес предложение на планерке. Его похвалили и дали добро на поиск исполнителей и реализацию проекта. Исполнителя он нашел, креатив придумал сам. Числу к 20-му все было готово и он показал руководству результат. Руководство как-то вяло отреагировало, не дало добро и не выдало денег на оплату труда исполнителя. Сотрудник был простым рядовым работником и побоялся сильно выбивать деньги, да еще и за то, что не вызвало бурного восторга у директора. И вот наступает 30-е декабря, день выплаты годовых бонусов, все собираются в большой переговорке.

Директор вещает, какие все молодцы, прибыль компании выросла на 30% по сравнению с прошлым годом и все сотрудники, кроме нашего инициативного, получат бонус в виде 2 зарплат. А наш инициативный сотрудник бонус не получает, потому что вызвался сделать проект с открыткой, а открытки на сайте нет, обещанный результат не достигнут.

Пример 2.

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

В понедельник он честно пишет в отчете о замене терминального сервера и сдает отчет начальнику. Начальник внимательно читает отчет и говорит: “Зачем ты мне это дал? Ты же не заменил почтовый сервер? Плановые работы не выполнены. Это нельзя провести как сверхурочные, извини.”

Продолжение следует.