Комментарии 9
НЛО прилетело и опубликовало эту надпись здесь
Условно процессы компании можно разделить на три типа:
RUN — это операционная деятельность
CHANGE — процессы развития, направленные на изменение и улучшение операционной деятельности
DISRUPT — прорывные решения, меняющие деятельность в корне
Для финансирования деятельности в рамках процессов RUN прекрасно подходит бюджетирование. Его можно делать на год и поквартально слегка корректировать.
Для DISRUPT процессов подходит финансирование типа венчурного фонда. И может реализовываться через фабрику идей и внутренний акселератор.
Процессы типа CHANGE также могут иметь свою процедуру принятия решений. Возможно, по типу Консента из Социократии 3.0
Что касается рисков и ответственности – то конечно, риски минимальны в случае RUN. Но тут нужно смотреть также и на возможные прорывные результаты и риски того, что некую идею кто-то реализует раньше и существенно подвинет компанию с её рыночных позиций.
RUN — это операционная деятельность
CHANGE — процессы развития, направленные на изменение и улучшение операционной деятельности
DISRUPT — прорывные решения, меняющие деятельность в корне
Для финансирования деятельности в рамках процессов RUN прекрасно подходит бюджетирование. Его можно делать на год и поквартально слегка корректировать.
Для DISRUPT процессов подходит финансирование типа венчурного фонда. И может реализовываться через фабрику идей и внутренний акселератор.
Процессы типа CHANGE также могут иметь свою процедуру принятия решений. Возможно, по типу Консента из Социократии 3.0
Что касается рисков и ответственности – то конечно, риски минимальны в случае RUN. Но тут нужно смотреть также и на возможные прорывные результаты и риски того, что некую идею кто-то реализует раньше и существенно подвинет компанию с её рыночных позиций.
Представим себе ситуацию. Клиент звонит в IT-компанию, которая ранее внедряла у него CRM-систему. Причем обращается не в службу поддержки, а к знакомому айтишнику, с которым раньше взаимодействовал: «У нас тут такая-то проблема». Айтишник оказывается перед выбором: переадресовать клиента в службу поддержки — в полном согласии с прописанной процедурой, или сначала вникнуть в суть вопроса. Вполне может оказаться, что в системе возникла критическая ошибка и стандартный путь отработки инцидента может обойтись слишком дорого для бизнеса клиента. Это не значит, что процедуры не важны. Но приоритет все же отдан другому.
А почему вы предполагаете, что «знакомый айтишник» вообще будет действовать в соответствии с ценностями компании? Ведь если он — наемный работник, как это обычно бывает, то его чисто материальные объективные интересы, мягко говоря, не совпадают с материальными интересами комании (а с точки зрения теории — так вообще находятся в антагонистичесом противоречии с ними). Почему он будет разделять ценности компании? И если его заставить это делать — то как это проконтролировать.
В приведенном примере «знакомый айтишник» совершенно не заинтересован взавливать на себя лишнюю работу, наоборот. А если правила компании этого от него требуют (например, запрещая автоматически передавать такие заявки в службу поддержки), то он все равно найдет выход, как избавиться это этой лишней работы — например, убедив клиента, что его пожелание выполнить невозможно. Да, предприятие потеряет клиента, но наемному работнику-то какая с того печаль?
PS Я готов дальше развивать эту тему, но, думаю, на пока хватит.
а в этих методиках куда ни глянь - всё надуманно, всё возведено в статус "не поддаётся оспариванию", за основу берётся выдуманное или нереальное поведение людей. Люди в своём начале ленивые, хитрые, алчные, преследующие свои цели, а не цели каких-то дядей. Конечно никто не будет хотеть брать на себя ответственность. Зачем она нужна, если это не восполняется и не оплачивается дополнительно. По мне agile - это совок. Никто ни за что не отвечает, всё общее, а значит - зачем выпендриваться - будь как все, ведь на фоне всех никто и не увидит твою ненужность. Качество? Да кому оно нужно, ведь работает как-нибудь, сроки просчитывать и исполнять - себя не уважать. А всё почему? Да потому что нет никакой ответственности за весь этот бардак. Ни product owner, ни scrum master, ни отдельные участники всяких там squad(ов) - никто ни за что не отвечает. Ни за костыльную архитектуру, ни за плохое качество, ни за отсутвие документации, ни за говно-код, ни за срыв сроков итд. - никто и ни за что не отвечает. Но в теории - методика классная. Всё может, всё обещает..
Это- надо-ж так - целую науку Project Management с формулами, с огромным багажем работающих механизмов снесли за раз и взамен предлагают только в теории работающие представления.
НЛО прилетело и опубликовало эту надпись здесь
Я услышал, что довольно чётко заявлена позиция. Думаю, спорить бесполезно. Однако, попытаюсь несколько аргументов привести в пользу позиции о «мягком управлении».
1) Есть теория Иксов и Игреков Мак Грегора. Согласно этой теории, люди не просто делятся на два типа, они занимают ту или иную позицию в зависимости от того, как к ним относятся. Если вы выстраиваете гиперконтроль, то сотрудники становятся Иксами — безответственными, ленивыми, которые могут и навредить при случае. Но те же сотрудники, попав в другую среду, могут проявить признаки Игреков – раскроют свой творческий потенциал, будут делать дело не ради похвалы или оценки, но ради того, чтобы делать своё дело наилучшим образом.
Сегодня популярной становится философия Стоиков. Стоики вне зависимости от внешнего окружения считают, что внешнее не имеет особого значения – «оно не моё». Зато выбор – это то, единственное, что «моё». Поэтому они выбирают наилучшим образом делать своё дело. А то, на что они не могут повлиять не должно особенно волновать.
2) Пару слов про Agile. Давайте посмотрим в корень — как пришли к идее гибкого подхода управления проектами. Есть 2 стороны: заказчик и исполнитель. Они изначально не доверяют друг другу и думают, что «противная сторона хочет меня нагреть». Но тем не менее, вступают в отношения – ведь одним нужен продукт, а другим деньги.
Проводят предпроектное исследование. Оформляют список требований. Трансформируют хотелки в фичи системы. Оценивают проект исходя из трудозатрат, как они видятся на старте. И приступают к работе. Но не всё так просто.
Заказчик понимает, что исполнитель и пальцем не пошевелит для создания какой-нибудь фичи, не прописанной в ТЗ. Исполнитель понимает, что заказчик не заплатит за переработку, если реализация фичи окажется сложнее, чем казалось изначально. Поэтому в ТЗ все перезакладываются. Прописывают фичи очень детально, включают в проект всё, что только могут придумать.
В результате проект переусложняется. Сроки его реализации становятся настолько большими, что уже по ходу реализации проекта могут существенно измениться требования. И в это время стороны начинают тыкать в ТЗ и в условия контракта. Дело делается, но уже не для того, чтобы создать ценность для клиента, а просто потому, что «нужно наконец закончить этот грёбанный проект».
3) К сожалению, мне известна и такая ситуация, когда заказчик хватается за Agile как за легализацию своего права вносить пожелания в проект на любом этапе и всю ответственность перекладывать на исполнителя, требуя от него соблюдения сроков по контракту. Я был в гибких проектах с обоих сторон и понимаю, что на заказчика такое взаимодействие также накладывает определённую ответственность и принятие правил игры.
Также я видел огромное количество карго реализаций Agile. Процессы есть, а духа нет. Культура и Ценности важнее процессов.
4) В Agile манифесте почему-то не обращают внимания на последнюю строку: «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева». Не отрицая, Карл! Весь наработанный арсенал инструментов и методик не отрицается, однако приоритет отдаётся человечности и фокус с формального исполнения контрактов и следования процедурам смещается к созданию ценности и живому взаимодействию.
Но помним МакГрегора — если заказчик смотрит на исполнителя как на Иксов, то нужно врубать Иксов и выстраивать линии обороны в виде контактов, ТЗ, регламентов.
1) Есть теория Иксов и Игреков Мак Грегора. Согласно этой теории, люди не просто делятся на два типа, они занимают ту или иную позицию в зависимости от того, как к ним относятся. Если вы выстраиваете гиперконтроль, то сотрудники становятся Иксами — безответственными, ленивыми, которые могут и навредить при случае. Но те же сотрудники, попав в другую среду, могут проявить признаки Игреков – раскроют свой творческий потенциал, будут делать дело не ради похвалы или оценки, но ради того, чтобы делать своё дело наилучшим образом.
Сегодня популярной становится философия Стоиков. Стоики вне зависимости от внешнего окружения считают, что внешнее не имеет особого значения – «оно не моё». Зато выбор – это то, единственное, что «моё». Поэтому они выбирают наилучшим образом делать своё дело. А то, на что они не могут повлиять не должно особенно волновать.
2) Пару слов про Agile. Давайте посмотрим в корень — как пришли к идее гибкого подхода управления проектами. Есть 2 стороны: заказчик и исполнитель. Они изначально не доверяют друг другу и думают, что «противная сторона хочет меня нагреть». Но тем не менее, вступают в отношения – ведь одним нужен продукт, а другим деньги.
Проводят предпроектное исследование. Оформляют список требований. Трансформируют хотелки в фичи системы. Оценивают проект исходя из трудозатрат, как они видятся на старте. И приступают к работе. Но не всё так просто.
Заказчик понимает, что исполнитель и пальцем не пошевелит для создания какой-нибудь фичи, не прописанной в ТЗ. Исполнитель понимает, что заказчик не заплатит за переработку, если реализация фичи окажется сложнее, чем казалось изначально. Поэтому в ТЗ все перезакладываются. Прописывают фичи очень детально, включают в проект всё, что только могут придумать.
В результате проект переусложняется. Сроки его реализации становятся настолько большими, что уже по ходу реализации проекта могут существенно измениться требования. И в это время стороны начинают тыкать в ТЗ и в условия контракта. Дело делается, но уже не для того, чтобы создать ценность для клиента, а просто потому, что «нужно наконец закончить этот грёбанный проект».
3) К сожалению, мне известна и такая ситуация, когда заказчик хватается за Agile как за легализацию своего права вносить пожелания в проект на любом этапе и всю ответственность перекладывать на исполнителя, требуя от него соблюдения сроков по контракту. Я был в гибких проектах с обоих сторон и понимаю, что на заказчика такое взаимодействие также накладывает определённую ответственность и принятие правил игры.
Также я видел огромное количество карго реализаций Agile. Процессы есть, а духа нет. Культура и Ценности важнее процессов.
4) В Agile манифесте почему-то не обращают внимания на последнюю строку: «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева». Не отрицая, Карл! Весь наработанный арсенал инструментов и методик не отрицается, однако приоритет отдаётся человечности и фокус с формального исполнения контрактов и следования процедурам смещается к созданию ценности и живому взаимодействию.
Но помним МакГрегора — если заказчик смотрит на исполнителя как на Иксов, то нужно врубать Иксов и выстраивать линии обороны в виде контактов, ТЗ, регламентов.
Всё правильно — «знакомый айтишник» и любой другой сотрудник, действующий в рамках регламентов и kpi совершенно не заинтересован в каких-либо результатах за пределами чётко очерченных его инструкциями.
И тут важно пояснить, почему я выбрал именно этот пример. Дело в том, что в хелпдеск до 99% запросов носит чисто «затупанский» характер и сотрудники ХД успокаивают и лечат клиентов, предполагая, что система работает правильно, а клиент тупит. И они легко пропускают проблемный запрос, принимаясь как обычно лечить клиента. Это большая редкость, когда на потоке сотрудник поддержки способен идентифицировать сбой системы и эскалировать инцидент.
В этом случае помогают «обходные двери». Просишь в ХД зарегистрировать заявку, а в это время сам пытаешься в обход регламентов придать этой заявке ускорение. Ценности AGILE, если они приняты в компании, создают возможность для таких обходных манёвров: «Люди и взаимодействие важнее процессов и инструментов».
А теперь о мотивации. Оно нужно сотруднику в принципе?
Лично я строю свои компании на основе ценностей. Основа корпоративной культуры — доверие. И чтобы люди могли самостоятельно принимать решение в сложных ситуациях, существуют ценности, задающие ориентиры. Если человек действовал согласно ценностям и что-то пошло не так, он прав. А если он бездействовал в ответственный момент – это тоже сигнал. Возможно, он чего-то не понимает, или понимает не так. Это повод поговорить.
И тут важно пояснить, почему я выбрал именно этот пример. Дело в том, что в хелпдеск до 99% запросов носит чисто «затупанский» характер и сотрудники ХД успокаивают и лечат клиентов, предполагая, что система работает правильно, а клиент тупит. И они легко пропускают проблемный запрос, принимаясь как обычно лечить клиента. Это большая редкость, когда на потоке сотрудник поддержки способен идентифицировать сбой системы и эскалировать инцидент.
В этом случае помогают «обходные двери». Просишь в ХД зарегистрировать заявку, а в это время сам пытаешься в обход регламентов придать этой заявке ускорение. Ценности AGILE, если они приняты в компании, создают возможность для таких обходных манёвров: «Люди и взаимодействие важнее процессов и инструментов».
А теперь о мотивации. Оно нужно сотруднику в принципе?
Лично я строю свои компании на основе ценностей. Основа корпоративной культуры — доверие. И чтобы люди могли самостоятельно принимать решение в сложных ситуациях, существуют ценности, задающие ориентиры. Если человек действовал согласно ценностям и что-то пошло не так, он прав. А если он бездействовал в ответственный момент – это тоже сигнал. Возможно, он чего-то не понимает, или понимает не так. Это повод поговорить.
А если он бездействовал в ответственный момент – это тоже сигнал. Возможно, он чего-то не понимает, или понимает не так. Это повод поговорить. Это повод поговорить.
Ну, поговорите — и что? И даже выясните, что человек действовал в своих объективных интересах — а у наемного работника успех предприятия в эти интересы не входит (все прибыли и убытки огребает владелец) — дальше-то что? Уволите этого — придет другой ровно с теми же объективными интересами.
Единственный вариант достичь успеха в вашем подходе — это сделать так, чтобы работник действовал вопреки своим объективным интересам. Я не утверждаю, что это невозможно: такие потенциальные сотрудники, как говорят о них в определенных кругах — не мамонты и не вымрут. Но массовая распространеность таких практик противоречит интересам работников в целом — ибо при прчих равных снижает их цену на рынке труда. Так что сами понимаете…
Лично я строю свои компании на основе ценностей. Основа корпоративной культуры — доверие. И чтобы люди могли самостоятельно принимать решение в сложных ситуациях, существуют ценности, задающие ориентиры.
Я родился, жил и даже немного работал в стране, элита которой пыталась реализовывать подобные подходы, причем ещё и убеждая работников из каждого утюга, что они являются совладельцами общенародной собственности, то есть — хозяевами, и работают на себя (на самом деле — нет, почем — см. например книгу М.Восленского «Номенклатура»). Работало это крайне посредственно: в ходу были поговорки типа «Тащи отсюда каждый гвоздь — ты здесь хозяин, а не гость». И тащили, кстати, массово.
В случае же частной фирмы ситуация ещё сложнее: там никак не замаскировать, что все выгоды достаются владельцу.
PS Картина со «знакомым айтишником», на самом деле — она вполне жизненная. Только вот корпоративные ценности тут не при чем. Люди организуют неформальное взаимодействие между собой, чтобы удовлетворять свои интересы — например, ускорять и упрощать решение своих задач (т.е. снижать свои личные трудозатраты): сегодня ты помог коллеге — завтра он может помочь тебе (кстати, ваш пример плох тем, что обратная помощь в нем совершенно не просматривается). Но вот менеджмент и предпринимателей за попытки паразитировать на таких отношениях надо бить по рукам.
PPS С работой техподдержкий мне приходилось иметь дело по обе стороны телефонного аппарата/системы заявок. Так что я — в курсе, как обращаться и с клиентами (по крайней мере — пробившимися через 1-ю линию), и с 1-й линией, и с техподдержкой другой организации в целом. Лично для меня тут вряд ли что надо объяснять.
Как человек, который работает с людьми, понимаю, что такая ситуация в принципе возможна, вещь люди бывают разные.
Единственное что отмечу, что знакома с принципами работы компании Смыслотека.
По-настоящему, открыла ее для себя после посещения их вебинара на тему «Промышленной безопасности». Оттуда у меня осталась картинка, смысл которой сгенерировали сами рабочие — Рабочий в униформе, перед которым стоит маленькая девочка, дающая ему перчатки, и надписью: «Папа там ток!» И еще пришло понимание что директивы можно опускать с верху в низ, и может быть их кто-то поймет и кто-то примет…, а можно и поднимать снизу вверх, когда сами сотрудники становятся амбасадорами этих изменений, так как понимают ценность каждой из них! Пришло понимание, что эту историю можно переложить на различные процессы и задачи, от малой до великой… и по ценностям в том числе…
Оградит ли это от возможных негативных решений сотрудников, которые вам не отследить? – пожалуй нет. Но по-хорошему, лично я уже приняла тот факт, что мерять нужно проценты в изменениях, конечно же там где это возможно.
Единственное что отмечу, что знакома с принципами работы компании Смыслотека.
По-настоящему, открыла ее для себя после посещения их вебинара на тему «Промышленной безопасности». Оттуда у меня осталась картинка, смысл которой сгенерировали сами рабочие — Рабочий в униформе, перед которым стоит маленькая девочка, дающая ему перчатки, и надписью: «Папа там ток!» И еще пришло понимание что директивы можно опускать с верху в низ, и может быть их кто-то поймет и кто-то примет…, а можно и поднимать снизу вверх, когда сами сотрудники становятся амбасадорами этих изменений, так как понимают ценность каждой из них! Пришло понимание, что эту историю можно переложить на различные процессы и задачи, от малой до великой… и по ценностям в том числе…
Оградит ли это от возможных негативных решений сотрудников, которые вам не отследить? – пожалуй нет. Но по-хорошему, лично я уже приняла тот факт, что мерять нужно проценты в изменениях, конечно же там где это возможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ценнее, еще ценнее