Помните веселую картинку про оргчарты разных компаний, где майкрософт во все стороны ощетинился пистолетами (ниже)?
Она иллюстрирует проблему кучи организаций, где на границе отделов возникает "мы против они". Неплохим решением является ликвидация границ и слияние в одну команду. На моей памяти это и правда в корне решало болезненные противостояния. Правда с этим методом есть один нюанс - "всякая проблема решается добавлением слоя абстракции, кроме проблемы слишком большого числа слоев абстракции" - слить прямо вот все-все-все не выйдет (ну или выйдет неприкольно). Где-то будут границы. Сольем все функции в команду полного цикла? Тогда будут границы между несколькими командами. Упс.
Еще вариант - команды разные, но начальник один, он рассудит. Тоже работает, но снова у начальника есть лимит емкости. Организационное перепахивание имеет свой предел эффективности.
Но часто упускают из виду второй эффективный инструмент сотрудничества - это не организационные перестановки, а дизайн правильных "институтов" коммуникации. То есть само-поддерживающихся систем, которые распространяют информацию и принуждают к определенному поведению.
Например, на заре своей работы я попал в компанию, где с духом кооперации все было не ахти, команда на команду и лидер на лидера волком смотрят, каких-то людей для кросс-командной координации не выделено, НО весь софт магически работал совместимо друг с другом БЕЗ особого администрирования над командами. Был простой институт в виде рассылки "я выпускаюсь и ручаюсь, что совместимость сохранил" + принцип "кто сломал, тот лох". Все. Два простых принципа и на нем сотрудничество работало много лет без какой-либо любви к сотрудничеству.
Вобщем, не стоит забывать про этот второй пласт инструментов. Орг.диаграмма, как ее не рисуй, все таки разделяет. А институты коммуникации объединяют.
Она иллюстрирует проблему кучи организаций, где на границе отделов возникает "мы против они". Неплохим решением является ликвидация границ и слияние в одну команду. На моей памяти это и правда в корне решало болезненные противостояния. Правда с этим методом есть один нюанс - "всякая проблема решается добавлением слоя абстракции, кроме проблемы слишком большого числа слоев абстракции" - слить прямо вот все-все-все не выйдет (ну или выйдет неприкольно). Где-то будут границы. Сольем все функции в команду полного цикла? Тогда будут границы между несколькими командами. Упс.
Еще вариант - команды разные, но начальник один, он рассудит. Тоже работает, но снова у начальника есть лимит емкости. Организационное перепахивание имеет свой предел эффективности.
Но часто упускают из виду второй эффективный инструмент сотрудничества - это не организационные перестановки, а дизайн правильных "институтов" коммуникации. То есть само-поддерживающихся систем, которые распространяют информацию и принуждают к определенному поведению.
Например, на заре своей работы я попал в компанию, где с духом кооперации все было не ахти, команда на команду и лидер на лидера волком смотрят, каких-то людей для кросс-командной координации не выделено, НО весь софт магически работал совместимо друг с другом БЕЗ особого администрирования над командами. Был простой институт в виде рассылки "я выпускаюсь и ручаюсь, что совместимость сохранил" + принцип "кто сломал, тот лох". Все. Два простых принципа и на нем сотрудничество работало много лет без какой-либо любви к сотрудничеству.
Вобщем, не стоит забывать про этот второй пласт инструментов. Орг.диаграмма, как ее не рисуй, все таки разделяет. А институты коммуникации объединяют.
В рубрике “зацепившись языками” - столкнулся с тезисом, что нельзя оценивать старые рынки для оценки популярности новых решений.
Примером было, что в 1980 году McKinsey обосновали компании AT&T, что рынок мобильной связи в США не превысит 900 тыс человек к 2000 году, поскольку мобильные тогда были громоздкими, неудобными и страшно дорогими. В реальности, уже к 1992 году мобильных в США было 12 млн и это число быстро росло (в 1994 уже 24 млн), а вес телефона снизился до “всего” 250г. К 2000му году число мобильных пользователей достигло 109 млн. Ошибка стоила AT&T 12.6 млрд долларов на покупку мобильного оператора, чтобы догнать.
Следующим примером было, что также глупо было бы оценить рынок авто по количеству лошадей. А вот здесь уже не работает - в США в 1910 году (доавтомобильная эра) было 25 млн лошадей. А в 1950 году (автомобильная эра) было … 25 млн автомобилей. Ну потому что автомобили первым делом заняли собственно ровно ту нишу, которую прежде занимали лошади.
Примером было, что в 1980 году McKinsey обосновали компании AT&T, что рынок мобильной связи в США не превысит 900 тыс человек к 2000 году, поскольку мобильные тогда были громоздкими, неудобными и страшно дорогими. В реальности, уже к 1992 году мобильных в США было 12 млн и это число быстро росло (в 1994 уже 24 млн), а вес телефона снизился до “всего” 250г. К 2000му году число мобильных пользователей достигло 109 млн. Ошибка стоила AT&T 12.6 млрд долларов на покупку мобильного оператора, чтобы догнать.
Следующим примером было, что также глупо было бы оценить рынок авто по количеству лошадей. А вот здесь уже не работает - в США в 1910 году (доавтомобильная эра) было 25 млн лошадей. А в 1950 году (автомобильная эра) было … 25 млн автомобилей. Ну потому что автомобили первым делом заняли собственно ровно ту нишу, которую прежде занимали лошади.
Tumblr
storyfund
McKinsey’s Estimates of the Cell Phone Market In 1980, AT&T commissioned McKinsey & Company to predict cell phone usage in the United States by 2000. The consulting group argued that cellular...
Вброшу очень старый и когда-то популярный, а ныне редко упоминаемый, но все еще не утративший актуальности текст про черных и белых обезьян.
Если вы его в своей жизни пропустили, то имеет смысл прочитать. Если когда-то читали, то перечитать еще раз.
Когда-то очень давно этот текст казался мне сатирой на менеджеров (белых обезьян). Потом сатирой на инженеров (черных обезьян). А сейчас мне кажется, что в нем есть много уроков на подумать.
Текст многогранный, и в зависимости от текущего уровня осознанности срабатывают разные наборы триггеров, захватывая внимание по разному и рассказывая разные истории. Каждый увидит в тексте разное, и в этом нет ничего плохого, но свое понимание можно использовать для само-калибровки. Пересказывать не буду, там чтение недолгое, а фрагменты не передают всей картины.
Если вы его в своей жизни пропустили, то имеет смысл прочитать. Если когда-то читали, то перечитать еще раз.
Когда-то очень давно этот текст казался мне сатирой на менеджеров (белых обезьян). Потом сатирой на инженеров (черных обезьян). А сейчас мне кажется, что в нем есть много уроков на подумать.
Текст многогранный, и в зависимости от текущего уровня осознанности срабатывают разные наборы триггеров, захватывая внимание по разному и рассказывая разные истории. Каждый увидит в тексте разное, и в этом нет ничего плохого, но свое понимание можно использовать для само-калибровки. Пересказывать не буду, там чтение недолгое, а фрагменты не передают всей картины.
Monkey-Habits
Книга "Повадки обезьян" (Юрий Шевченко)
По каким законам живут большие компании и международные корпорации? Обязательный учебный материал для получения степени MBA (Master of Banana Administration).
ПРИМИТИВНЫЕ РЕЦЕПТЫ
При каких-то совместных проектах в большой организации может возникать неприятное когнитивное искажение, когда “исполнитель” вкалывает над скоростным решением проблем, а “заказчику” все мало и он жалуется, как вы плохо стараетесь и медленно его обслуживаете.
Возникает это, если команды “исполнитель” и “заказчик” из разных организаций (не образуют одной большЕй команды) плюс “исполнитель” делает кроме этого проекта еще и какую-то обычную работу или даже много других работ.
Искажение возникает от того, что свои собственные задачи “заказчик” видит как “длящиеся”, то есть занимающие время и ресурс. А вот такие проблемы на стороне “заказчик” воспринимает как “точечные” - я багу завел, а они пусть быстренько исправят. Не возникает понимания, что при этом тоже тратится какой-то ограниченный ресурс, и что дробь задача/ресурс образует какое-то существенное время.
Этому более подвержены ситуации, которые кажутся “заказчику” как баги (отклонения от ожиданий). И менее подвержены задачи, когда “заказчик” явно хочет, чтобы на той стороне что-то очень сильно переделали.
Как решение “исполнителю” надо уходить от отчета на стендах галочками “сделал”/“не сделал” и переходить к отчету “работаю над этим до такого-то числа, а потом над этим до такого-то”, формируя восприятие себя как такой же ресурс “заказчика”, что и его собственный.
Другое решение это, конечно же, просто явная передача человека "заказчику" на время , но это не всегда приемлемо.
При каких-то совместных проектах в большой организации может возникать неприятное когнитивное искажение, когда “исполнитель” вкалывает над скоростным решением проблем, а “заказчику” все мало и он жалуется, как вы плохо стараетесь и медленно его обслуживаете.
Возникает это, если команды “исполнитель” и “заказчик” из разных организаций (не образуют одной большЕй команды) плюс “исполнитель” делает кроме этого проекта еще и какую-то обычную работу или даже много других работ.
Искажение возникает от того, что свои собственные задачи “заказчик” видит как “длящиеся”, то есть занимающие время и ресурс. А вот такие проблемы на стороне “заказчик” воспринимает как “точечные” - я багу завел, а они пусть быстренько исправят. Не возникает понимания, что при этом тоже тратится какой-то ограниченный ресурс, и что дробь задача/ресурс образует какое-то существенное время.
Этому более подвержены ситуации, которые кажутся “заказчику” как баги (отклонения от ожиданий). И менее подвержены задачи, когда “заказчик” явно хочет, чтобы на той стороне что-то очень сильно переделали.
Как решение “исполнителю” надо уходить от отчета на стендах галочками “сделал”/“не сделал” и переходить к отчету “работаю над этим до такого-то числа, а потом над этим до такого-то”, формируя восприятие себя как такой же ресурс “заказчика”, что и его собственный.
Другое решение это, конечно же, просто явная передача человека "заказчику" на время , но это не всегда приемлемо.
В разговоре вслыла идея, что индексом цитирования Дилберта можно надежно мерить мораль в организации, даже если люди не хотят отвечать на опросники. Чем больше этих веселых картинок ходит - тем выше недовольство и напряжение.
Как показало гугление - "все уже украдено до нас" и Dilbert Index придумали 12 лет назад. Впрочем, судя по малому числу упоминаний - это изобретение осталось незамеченным.
Если бы сайт dilbert.com оставался жив, то могли бы сделать рейтинг по компаниям, продавать им аналитику, написать своих ботов для мессенджеров, чтобы считать репосты. Распространяемая картинка автоматически бы идентифицировала собой беспокояющую тему. Но это все в какой-то альтернативной реальности.
Как показало гугление - "все уже украдено до нас" и Dilbert Index придумали 12 лет назад. Впрочем, судя по малому числу упоминаний - это изобретение осталось незамеченным.
Если бы сайт dilbert.com оставался жив, то могли бы сделать рейтинг по компаниям, продавать им аналитику, написать своих ботов для мессенджеров, чтобы считать репосты. Распространяемая картинка автоматически бы идентифицировала собой беспокояющую тему. Но это все в какой-то альтернативной реальности.
Некоторый парадокс получается с применением AI для автоматических переводов. Мы переводим продукт на очень много языков и это стоит приличных денег, поэтому такая оптимизация интересна. Но это все-таки не рилзы переводить, продукт платный, есть ответственность и есть какие-то стандарты качества.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
По моим наблюдениям основатели небольших компаний при их поглощении "стратегом" (бОльшим бизнесом) не часто приживаются. Сужу как по знакомым, так и по статьям от поглощенных в гугл, мс и тп, так и по нашей конторе. Детальных примеров в памяти уже довольно много, так что можно что-то субъективно обобщить:
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.
Никакой пользы в этой заметке, но однако забавно какой путь в признании проделал слак за эти годы
- баловство для отдельных гиков в инженерке, инженерное руководство косится с подозрением
...
- разработка наглухо подсела на слак, инженерное руководство придумывает правила пользования/модерации, соседнии отделы игнорируют и морщатся, периодически грозятся прикрыть (но это уже нереально)
...
- вся компания сидит в слак, попытки его грохнуть забыты, но по серьезным вопросам "продублируйте в почту"
...
- пожилые очень бизнесовые дядечки говорят, что хватить уже пожалуйста мусорить в почте, давайте пожалуйста все в слак - нам так удобнее. Серьезная веха.
Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)
- баловство для отдельных гиков в инженерке, инженерное руководство косится с подозрением
...
- разработка наглухо подсела на слак, инженерное руководство придумывает правила пользования/модерации, соседнии отделы игнорируют и морщатся, периодически грозятся прикрыть (но это уже нереально)
...
- вся компания сидит в слак, попытки его грохнуть забыты, но по серьезным вопросам "продублируйте в почту"
...
- пожилые очень бизнесовые дядечки говорят, что хватить уже пожалуйста мусорить в почте, давайте пожалуйста все в слак - нам так удобнее. Серьезная веха.
Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)
К вопросу о возвращении в офисы - в этой карикатуре есть большая доля правды.
Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.
В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.
В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.
И с тех пор этот процесс успел усугубиться тем, что за период повсеместной удаленности команды только больше перемешались, поэтому близость в физическом офисном пространстве уже давно не означает совместной работы - коллеги могут быть в офисе, но в совсем другом.
Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.
В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.
В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.
И с тех пор этот процесс успел усугубиться тем, что за период повсеместной удаленности команды только больше перемешались, поэтому близость в физическом офисном пространстве уже давно не означает совместной работы - коллеги могут быть в офисе, но в совсем другом.
Наверное уже все слышали, про шумное исследование, что 10% инженеров в компаниях (смотрели на выборку в 50 тыс человек) не делают практически ничего.
Не то, чтобы нельзя было такого допустить - в достаточно большой компании, наверное, и слона спрятать можно.
Но к сожалению, статья (первоисточник) не отвечает достаточно детально про методику сбора данных. А то на моей памяти был случай, что установили моим бывшим коллегам софтинку, которая считала их продуктивность с оплатой по часам. И этот софт за продуктивность считал кодинг, а вот например сидение в терминале за настройкой и отладкой инфраструктуры он продуктивным делом не считал, к некоторой печали инженеров. Вот такой был "налог" на инфраструктурные задачи - но вроде оно там достаточно равномерно распределялось по людям, чтобы никого не задевать смертельно.
А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.
https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing
Не то, чтобы нельзя было такого допустить - в достаточно большой компании, наверное, и слона спрятать можно.
Но к сожалению, статья (первоисточник) не отвечает достаточно детально про методику сбора данных. А то на моей памяти был случай, что установили моим бывшим коллегам софтинку, которая считала их продуктивность с оплатой по часам. И этот софт за продуктивность считал кодинг, а вот например сидение в терминале за настройкой и отладкой инфраструктуры он продуктивным делом не считал, к некоторой печали инженеров. Вот такой был "налог" на инфраструктурные задачи - но вроде оно там достаточно равномерно распределялось по людям, чтобы никого не задевать смертельно.
А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.
https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing
404 Media
Are Overemployed ‘Ghost Engineers’ Making Six Figures to Do Nothing?
"We have data on the performance of >50k engineers from 100s of companies. ~9.5% of software engineers do virtually nothing: Ghost Engineers.”
Пока все репостят скандал с провели опрос по удовлетворенности и уволили всех неудовлетворенных, попробуем быть на шаг впереди и прочтем, что автор первого поста описывает это как PR ход. Завирусилось знатно, надо признать.
Невозможно, конечно, точно сказать было ли это реально PR ходом или оперативно переиграли.
https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/
Невозможно, конечно, точно сказать было ли это реально PR ходом или оперативно переиграли.
https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/
Помните смешной текст про то, что все животные делятся на
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.
Я с подобным периодически болезненно сталкиваюсь. Например, вот возник список клиентов и категории "которым надо позвонить" и "которым звонили". Технически это два независимых флага, сочетания которых гибко передают все богатство сочетаний - и не надо было звонить, но позвонили, и надо было, но еще нет. Но жить с таким трудно - когда эти данные циркулируют, то возникает лишняя когнитивная нагрузка и риски неправильной интерпретации. Например, "надо было позвонить 9м и позвонили 9м - о, все процесс закончен! - нет, еще двум надо позвонить - как так? - ну позвонили двум, которым не надо, а двое, которым надо, еще остались...".
Это может показаться смешным, может показаться нестоящим внимания, но об подобное люди спотыкаются, тратят время каждый раз на выяснение, периодически делают вокруг этого ошибки. Если таких процессов много, или если они большие, или если они важные - это создает паразитную когнитивную нагрузку в организации. Подобное стоит вычищать и предотвращать, чтобы не похоронить организацию под горой путаницы, неуверенности и ложных интерпретаций.
Этот конкретный пример из процесса продажников, но такая же задача возникает в рефакторинге, в реорганизациях, в изменениях интерфейса продуктов - кому, что ближе.
Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.
Тогда относительно простые инструменты и минимум внимания позволяют с минимумом ошибок переваривать довольно массивные критические проекты (в смысле, что ошибки в них очень дорого обходятся).
Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.
Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.
Я с подобным периодически болезненно сталкиваюсь. Например, вот возник список клиентов и категории "которым надо позвонить" и "которым звонили". Технически это два независимых флага, сочетания которых гибко передают все богатство сочетаний - и не надо было звонить, но позвонили, и надо было, но еще нет. Но жить с таким трудно - когда эти данные циркулируют, то возникает лишняя когнитивная нагрузка и риски неправильной интерпретации. Например, "надо было позвонить 9м и позвонили 9м - о, все процесс закончен! - нет, еще двум надо позвонить - как так? - ну позвонили двум, которым не надо, а двое, которым надо, еще остались...".
Это может показаться смешным, может показаться нестоящим внимания, но об подобное люди спотыкаются, тратят время каждый раз на выяснение, периодически делают вокруг этого ошибки. Если таких процессов много, или если они большие, или если они важные - это создает паразитную когнитивную нагрузку в организации. Подобное стоит вычищать и предотвращать, чтобы не похоронить организацию под горой путаницы, неуверенности и ложных интерпретаций.
Этот конкретный пример из процесса продажников, но такая же задача возникает в рефакторинге, в реорганизациях, в изменениях интерфейса продуктов - кому, что ближе.
Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.
Тогда относительно простые инструменты и минимум внимания позволяют с минимумом ошибок переваривать довольно массивные критические проекты (в смысле, что ошибки в них очень дорого обходятся).
Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.
Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку
Смотрел, что недавно в confluence выкатили функции встроенных баз данных - очень прикольная штука, но оказалось, что к ним еще не был готов бекап/рестор, что для более-менее крупной организации, конечно стопор для активного использования. Это заставило задуматься еще раз про в каких местах правильно срезать углы, если надо выкатить продукт пораньше.
Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.
Тогда это несколько необычно было, пытались писать полные требования со всеми нужными функциями, а потом по ним реализовывать.
Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.
Тогда это несколько необычно было, пытались писать полные требования со всеми нужными функциями, а потом по ним реализовывать.