Team 2.0

Не так важно, насколько плохи ваши процессы, важно, что вы об этом знаете.

Анализируя различные аспекты работы компаний, то, как решаются те или иные управленческие задачи и разрешаются конфликтные ситуации, я пришёл к выводу, что многие из них, если не все, могут быть сведены к двум дилеммам:

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

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

Статический vs Динамический
Сталкиваясь с той или иной задачей, вы всегда можете использовать некую формальную «теорию» и в её базисе находить решения. Например, приняв, что в вашей организационной структуре, у сотрудника может быть только один менеджер верхнего уровня, вы легко выстроите субординацию, но в тоже время столкнётесь с трудностями при отражении связей для ресурс-менеджеров, деливери-менеджеров, разделения ресурсов, микро менеджмента сотрудников, менеджмента со стороны заказчика(ов), внутренних технологических групп и пр.

Построение же любой динамической среды, потребует от Вас большего внимания и усилий для поддержания её в актуальном состоянии. Простой пример — waterfall vs agile. Но оно того стоит.


C.E.P.U.(Zorro way)

Социальная инженерия

Попробуем рассмотреть компанию с точки зрения социальной сети. На рисунке ниже отражены некоторые из возможных связей.

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

Вот неполный список, элементы которого постоянно находились в фокусе внимания:

  • Recommendations: отражение связи между сотрудником компании и потенциальным сотрудником; база рекомендаций; рекомендации для сотрудников, которые покидают компанию
  • Interviewing: сохранение связей кто, когда и с кем проводил интервью; системное хранение результатов; использование при повторных собеседованиях и как входные данные при пересмотрах зарплат
  • Probation period: постановка конкретных целей, сбор информации от максимального количества сотрудников; фактически является подмножеством Performance review
  • Informal leaders\Experts: выявление и поощрение
  • Grading: «вес» сотрудника определяется только отзывами коллег, никаких Сеньоров-23 и Архитекторов-24
  • Performance review: динамическое формирование и достижения целей
  • Trainings: по облаку тегов улучшений можно составлять списки тренингов в тех или иных областях, по тем или иным технологиям
  • Bonuses: награда должна находить героя, всегда
  • Loyalties and Antipathies: специализированные отчёты менеджеров и анализ парных оценок, позволит точнее проводить мониторинг внутреннего климата
  • Publicity: прозрачность менеджеров, оценок и как следствие, повышение объективности

Архитектура

В основе системы лежат две ключевые идеи:
  • Расширенные связи. Необязательно каждой компании реализовывать все возможные типы связей : People manager, Project manager, Delivery manager, Supervisor, Interviewer, ... Более того, потребность тех или иных связях может динамически появляться и исчезать с течением времени. Главное, чтобы связи могли создаваться быстро и просто, отражая динамику. Если я на две недели хочу приставить к новичку эксперта из своей команды, я не хочу ждать неделю, пока команда поддержки зарегистрирует эту связь и тем более где-то заводить тикет и получать 100500 нотификаций по почте.
  • Три типа отметок: like, improve, info. В самом общем случае любой сотрудник может создать отметку для любого другого сотрудника. Отдельная задача — это ранжирование оценок, в соответствии со связями. Два первых типа говорят сами за себя, третий нужен для хранения информации общего плана — идей, суждений, предположений.

Вот как может выглядеть некий снимок отметок за какой-то интервал.

Резюмируя, технологически это facebook/vk, что кому по душе, с более строгой системой списков и рейтингом.

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

Можно ли пасти котов вот так?

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


17 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Построение сети это не самоцель, это средство.

Попробуйте провести следующий мысленный эксперимент.
Пройдитесь по списку выше [Recommendations..Publicity] и посмотрите решаются ли данные задачи у Вас в компании и какими средствами.
В каждом отдельном случае это может быть excel-файл с отчётом, личная беседа, письмо, собственный внутренний корпоративный велосипед и пр.

В предложенной структуре, «социальная сеть» позволяет унифицировать взаимоотношения для эффективного решения ряда задач.

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

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

ни к чему хорошему подобные метрики не приведут. только лишняя бюрократия.

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

— Как это схема должна отражаться на должности и зарплате?

Все эти лайки, если автор подразумевает аналоги лаков facebook/vk, и если они имеют влияние на оценку эффективности сотрудника, могут привести к увеличению риска принятия популистских решений в производственных задачах.

Это скорее напоминает «эскиз» статьи чем статью — слишком уж сжатый материал.

Почему я не затронул реализацию ответил ниже @"Andrei Boiko

Junior Tester в GlobalLogic"

— Так и не понятно, чему или кому можно будет ставить отметки? Сотрудникам? Артефактам проектов? Процессам? Тикетам?

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

Но я фокусировался именно на покрытии взаимодействий между членами коллектива.

— Проставление лайков тайное или открытое?

Полностью публичное с кратким описанием, примеры @"Andrei Boiko

Junior Tester в GlobalLogic«. За исключением специальных типов артефактов, таких как мониторинг лояльности, например. Здесь видимость точно по линии People management и только вниз.

— Каков механизм регулирования видимости этих отметок?

Как уже сказал, в идеальном случае — полный доступ, но конкретная компания в конкретных случаях вправе вводить ограничения.

— Могут ли ставить отметки подчиненные начальникам?

Обязательно. Это как раз один из элементов увеличения publicity менеджмента и усиления обратной связи. Посмотрите на третий рисунок, там есть стрелочки вверх.

— Как это схема должна отражаться на должности и зарплате?

Одно из назначений системы — сбор и систематизация материалов для Performence review. К примеру, в начале года, вы определились куда хочет расти сотрудник по карьере и финансово, определили objectives и acceptance criteria. Все это попало в систему в виде improve отметок. Неизбежно за эти полгода возникнут коррективы: какие-то цели могут стать не актуальными, могут добавиться новые, человек может уйти на другой проект и станет необходимость в корректировке целей и пр. Но самое главное вне зависимости от таких вот воздействий, через полгода у вас будет объективная максимально актуальная картина по сотруднику.

Я специально не упомянул сейчас лайки\рейтинги — это просто ещё один из инструментов, который может быть внедрен для характеристики уровня «социальности» сотрудника и если компания хочет и может использовать его для поощрений.

Все эти лайки, если автор подразумевает аналоги лаков facebook/vk, и если они имеют влияние на оценку эффективности сотрудника, могут привести к увеличению риска принятия популистских решений в производственных задачах.

В принципе, попытался ответить выше.

Идея «плюсовать» и «минусовать» коллег, в принципе, неплохая. Многое, конечно, будет зависеть от реализации.
А вот с динамическими связями, думаю, не получится. Понятно что гибкая система более эффективна. Но начальство (да и клиенты) обычно предпочитают контроль и предсказуемость эффективности. Особенно если это касается финансов (а рабочее время = деньги). Т.е. определенная степень бюрократии и формализма неизбежна.
Даже просто подойти к человеку с другого проекта что-то обсудить на полчасика — уже возникают вопросы («кто за это заплатит?», «что можно говорить, что нет?» и т.д.). Не говоря уже про соответствия ISO стандартам, где на все должны быть записи («100500 нотификаций по почте»).

Единственный выход: максимально полная автоматизация этой бюрократии. Что бы с одной стороны сотрудникам не надо было ничего заполнять, а с другой — у начальства всегда были полные отчеты кто и что делал. Но кто эту автоматизацию оплатит?

Идея «плюсовать» и «минусовать» коллег, в принципе, неплохая. Многое, конечно, будет зависеть от реализации.

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

Даже просто подойти к человеку с другого проекта что-то обсудить на полчасика — уже возникают вопросы («кто за это заплатит?», «что можно говорить, что нет?» и т.д.).

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

ISO стандартам, где на все должны быть записи («100500 нотификаций по почте»)

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

Единственный выход: максимально полная автоматизация этой бюрократии. Что бы с одной стороны сотрудникам не надо было ничего заполнять, а с другой — у начальства всегда были полные отчеты кто и что делал. Но кто эту автоматизацию оплатит?

Вы совершенно точно описали идею, не зря я ссылался на facebook/vk как на примеры реализаций.

Но кто эту автоматизацию оплатит?

Компания, которая хочет перейти с уровня Big/Static -> Big/Dynamic

Компания, которая хочет перейти с уровня Big/Static -> Big/Dynamic
Компании уровня «Big» в Украине это, в подавляющем большинстве, аутсорс — бодишопы. Они получают свои 10-15% прибыли на разнице внутренних и внешних рейтов девелоперов. И разница эта все больше уменьшается.
По моему опыту в «Big» компании крайне неохотно тратят деньги на любые внутренние разработки. Основное правило такое: если клиент это не оплатит, то надо постараться этого не делать. Это касается всего: покупки софта, железа, тренингов, даже тимбилдингов.
А разработка «внутрикомпанейкого фейсбука» наверняка влетит в копеечку. В то время, как очевидных экономических выгод для компании не видно (клиент за «эффективность в решении внутренних задач» больше не заплатит).
Полностью разделяю то, что Вы написали. В этих вопросах мы полностью когерентны

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

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

Это краткое описание — мой взгляд на внутренние процессы компаний (не только аутсорсовых) и предложение по схеме Copy->Transform->Combine

Что такое improve?
Что такое like? (критерии)
Как система защищена от вандализма? (с этого нужно начать)
Сотрудники МОГУТ создать «отметку» для любого другого или ДОЛЖНЫ?
Что делать если отметок никто не поставит? Всем или отдельным точкам графа.

Если часть сотрудников после внедрения откажется участвовать и будут периодически возмущатся (или молчать, с понятными последствиями), что делать тогда?

Как система защищена от вандализма? (с этого нужно начать)

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

Что такое improve?

Что такое like? (критерии)

improve — ваше мнение о том что какой-то аспект работы нужно улучшить: ваш интерн путается в назначении static, ваш сеньор вечно рисует никому не понятные схемы — пора бы выучить UML, а вот этот вот товарисч постоянно хамит, ...

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

Что делать если отметок никто не поставит? Всем или отдельным точкам графа.

Если часть сотрудников после внедрения откажется участвовать и будут периодически возмущатся (или молчать, с понятными последствиями), что делать тогда?

Эти вопросы относятся не к данной системе, они вообще относятся к фундаментальным вопросам взаимодействия.
Вы когда-нибудь присутствовали при введении новой, строгой отчётности в Jira, MSProject да просто в excel-e на проекте?

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

Можно... Вот только для маленьких команд слишком сложная система, а для больших ... боюсь никаких ревью не хватит, ибо текучка мидлового (да и не только) персонала слишком велика..
А как следствие — кто ж будет оценивать кого???

Да и при получении такой оценки очень сомнительна мотивация сотрудника в духе: «вот тут подтяни и ты получишь много вкусного!». Да он просто уйдет к конкуренту...

Вот только для маленьких команд слишком сложная система

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

а для больших ... боюсь никаких ревью не хватит, ибо текучка мидлового (да и не только) персонала слишком велика..

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

Оптимизировать нужно всегда! Думаю, что подобные критерии/методы уже используются исподволь и остается их лишь формализаовать и «запидалить», дабы облегчить жизнь простым смертным :)
А вот Вам за подобную формализацию и наглядность — Спасибо :)

Подписаться на комментарии