Комментарии 31
В случае с выбором одного варианта из двух предложенных мы, конечно, получим одного человека (команду), мотивированную внедрить решение. Но мы также гарантированно, с вероятностью 100% получим одного обиженного на ровном месте человека (команду), которая старалась, а получила шиш.
В случае с набором скриптов для бенчмарка я бы сказал: «Окей, отлично, давайте посмотрим теперь насколько хорошо ваше решение расширяемо и масштабируемо. Мне кажется нужно добавить ещё бенчмарки Х, Y и Z, запускать тесты параллельно на трёх серверах, а суммарный отчёт высылать на почту разработчикам. Давайте посмотрим, в каком решении это всё будет сделать быстрее.» Да, мы потратим ещё 1 день на выполнение этих задач, но в итоге:
В случае с набором скриптов для бенчмарка я бы сказал: «Окей, отлично, давайте посмотрим теперь насколько хорошо ваше решение расширяемо и масштабируемо. Мне кажется нужно добавить ещё бенчмарки Х, Y и Z, запускать тесты параллельно на трёх серверах, а суммарный отчёт высылать на почту разработчикам. Давайте посмотрим, в каком решении это всё будет сделать быстрее.» Да, мы потратим ещё 1 день на выполнение этих задач, но в итоге:
- в продакшн пойдёт действительно более лёгкое в поддержке и расширяемости решение
- поддерживать его будет гордая за результат своей работы команда
- вторая команда, решение которой было забраковано, лично убедиться, что произошло это не «от балды» и не по причинам каких-то подковёрных интриг, а потому, что они не смогли добавить 3 новых бенчмарка быстрее конкурентов или потому, что их решение не масштабируется на несколько серверов. Никаких «собственноручно придуманных метрик», только соответствие реалий поставленным задачам.
Вы не учитываете вариант, что обе команды справятся. Этак вы до бесконечности будете тратить ресурсы на доработку скрипта.
Принудительный выбор варианта с обязательством поддержки и гарантией поощрения (в виде плюса при аттестации) проблему «обиженных» снимает.
Принудительный выбор варианта с обязательством поддержки и гарантией поощрения (в виде плюса при аттестации) проблему «обиженных» снимает.
Принудительный выбор варианта с обязательством поддержки и гарантией поощрения (в виде плюса при аттестации) проблему «обиженных» снимает.
тут несколько меняется полярность проблемы:
Одна команда получит плюсик и премию, а другой ещё придётся поддерживать и развивать проект.
Во-первых, справятся они не одновременно.
Во-вторых, никогда в жизни не поверю, что сделанное изначально было идеально — всегда есть, что поправить.
В случае если обе команды справились быстро, результат получился отличный — боже ты мой, да в этом проекте и с этими людьми вообще никаких проблем быть не может, живи и радуйся!
Во-вторых, никогда в жизни не поверю, что сделанное изначально было идеально — всегда есть, что поправить.
В случае если обе команды справились быстро, результат получился отличный — боже ты мой, да в этом проекте и с этими людьми вообще никаких проблем быть не может, живи и радуйся!
Поправить всегда есть что — вот в процессе поддержки и поправят. )) Когда им пользователи скриптов напишут свои душевные комментарии.
Добавлю, что там в реальной ситуации скрипты были одинаково неплохими. Устроить соц.соревнование команд — интересная идея, но в случае более-менее одинаковых решений имхо спросить. кто будет поддерживать — проще.
Добавлю, что там в реальной ситуации скрипты были одинаково неплохими. Устроить соц.соревнование команд — интересная идея, но в случае более-менее одинаковых решений имхо спросить. кто будет поддерживать — проще.
Я не менеджер ни разу, но кейсы очень интересные. С нетерпением жду продолжения) Спасибо!
1) Кто поддерживает решение в дальнейшем, тот и выбирает вариант реализации скриптов.
2) Обеим командам объявить по 50% бонуса (половина лучше, чем ничего) и объявить на будущее, что для получения 100% надо убедиться, что решение будет актуальным, то есть выяснить, кто будет ответственным и согласовать свои проактивные действия с ним.
2) Обеим командам объявить по 50% бонуса (половина лучше, чем ничего) и объявить на будущее, что для получения 100% надо убедиться, что решение будет актуальным, то есть выяснить, кто будет ответственным и согласовать свои проактивные действия с ним.
Без критериев усточивости решения писать о принятии таких решений, мягко говоря, странно, но это же тренинг да.
Ребята, интересно было бы увидеть побольше новых (буквально – свежих) кейсов. Всё что на хабре, в основном, повторение белой и черной книги, ну и прочих ваших материалов. Они все отличные! Но давайте же и свежести, буду искренне благодарен. Но мне вот что интересно ещё было бы. Вы черпаете эти кейсы из России середины нулевых, а каков расклад кейсов России середины десятых? Можно было бы сравнить тогда-сегодня, ведь наверняка есть изменения.
Спасибо за то, что следите за нами! )) Старые кейсы хороши тем, что они проверенно интересные, но плохи тем, что кто-то про них еще знает. Свежих кейсов есть вагон и маленькая тележка, дойдем и до них.
Сравнить кейсы не возьмусь — несмотря на то, что лично проанализировал под 400 кейсов, какой-то закономерности, которая бы отличала десятые от нулевых, не заметил. Все те же проблемы с людьми в команде, с заказчиками, начальниками и т.д.
Мне кажется, тут дело не во времени, а в том, что даже мир ИТ компаний — это, на самом деле, несколько миров. Есть компании, скажем так, западного толка, которые хотят быть похожими на корпорации, модные стартапы или еще что-то, есть компании со своей историей (тяжелой или интересной), там своя специфика — и так далее.
Сравнить кейсы не возьмусь — несмотря на то, что лично проанализировал под 400 кейсов, какой-то закономерности, которая бы отличала десятые от нулевых, не заметил. Все те же проблемы с людьми в команде, с заказчиками, начальниками и т.д.
Мне кажется, тут дело не во времени, а в том, что даже мир ИТ компаний — это, на самом деле, несколько миров. Есть компании, скажем так, западного толка, которые хотят быть похожими на корпорации, модные стартапы или еще что-то, есть компании со своей историей (тяжелой или интересной), там своя специфика — и так далее.
Давно слежу и вдохновляюсь, спасибо за ваш труд!
На мой взгляд, должны были повлиять вот такие моменты.
1. Способы коммуникации: больше онлайна, нормальный интернет в моём Нижнем Новгороде заполучился только в 2007. Сейчас у нас огрномный выбор: тут тебе и тикеты на гитхабе, и почта с гугл.инбоксом, и slack. Google.Hangouts, из которого я так и не смог дёрнуть историю. Хотя логи ICQ с 2003 по 2013 у меня отлично хранятся до сих пор :) Хорошо или плохо такое разнообразие?
2. Модные течения: писать будем на Node.JS, или может быть возьмём его форк (пока ещё только один известен), или ничего не признаем кроме Эрланга, а какой из 100 фреймворков для клиента выберем? Руби уже не тот? На мой взгляд, в 2005 выбор инструментов был весьма скуднее.
3. Больше интересных работодателей, больше контрактников и фрилансеров (в силу удобства взаимодействия). Сейчас найти отличного исполнителя – это (часто) очень эффективно решаемая на биржах задача. Люди стали более мобильными, и более легко меняют места работы. Высокое проникновение ИТ в России в целом, много мест, где на тебя будет хороший спрос.
4. Методологический холивар: раньше как-то просто работали, вот есть цель, вот мы к ней движемся. И тесты, знаете ли, были, и планёрки. Теперь у вас большая проблема – 5 или 10 минут делать стендап, в 10 или 11 утра? Как там у нас считают лучшие мастера. А может быть ну его скрам, давайте по канбану? Скрамбан? Или вот давайте выберем одну из 25 доступных таск-трекеров. Сидишь на битбакет вместо гитхаба, верстаешь в ворде вместо маркдаун, ну ты странный. TDD/DDD/CQRS. И т.д.
То есть, возможность огромного выбора – это явно и хорошо, но явно и плохо. Обостряет, если хотите, аналитический паралич, провоцирует ненужные обсуждения и потери времени, обостряет субъективные суждения. Как-то так мне это видится. Поправьте ход моих мыслей, если я сильно не прав :)
На мой взгляд, должны были повлиять вот такие моменты.
1. Способы коммуникации: больше онлайна, нормальный интернет в моём Нижнем Новгороде заполучился только в 2007. Сейчас у нас огрномный выбор: тут тебе и тикеты на гитхабе, и почта с гугл.инбоксом, и slack. Google.Hangouts, из которого я так и не смог дёрнуть историю. Хотя логи ICQ с 2003 по 2013 у меня отлично хранятся до сих пор :) Хорошо или плохо такое разнообразие?
2. Модные течения: писать будем на Node.JS, или может быть возьмём его форк (пока ещё только один известен), или ничего не признаем кроме Эрланга, а какой из 100 фреймворков для клиента выберем? Руби уже не тот? На мой взгляд, в 2005 выбор инструментов был весьма скуднее.
3. Больше интересных работодателей, больше контрактников и фрилансеров (в силу удобства взаимодействия). Сейчас найти отличного исполнителя – это (часто) очень эффективно решаемая на биржах задача. Люди стали более мобильными, и более легко меняют места работы. Высокое проникновение ИТ в России в целом, много мест, где на тебя будет хороший спрос.
4. Методологический холивар: раньше как-то просто работали, вот есть цель, вот мы к ней движемся. И тесты, знаете ли, были, и планёрки. Теперь у вас большая проблема – 5 или 10 минут делать стендап, в 10 или 11 утра? Как там у нас считают лучшие мастера. А может быть ну его скрам, давайте по канбану? Скрамбан? Или вот давайте выберем одну из 25 доступных таск-трекеров. Сидишь на битбакет вместо гитхаба, верстаешь в ворде вместо маркдаун, ну ты странный. TDD/DDD/CQRS. И т.д.
То есть, возможность огромного выбора – это явно и хорошо, но явно и плохо. Обостряет, если хотите, аналитический паралич, провоцирует ненужные обсуждения и потери времени, обостряет субъективные суждения. Как-то так мне это видится. Поправьте ход моих мыслей, если я сильно не прав :)
Мне вот кажется, что шаг №2 именно в таком виде — вреден. Если о подбрасывании монетки узнают обе команды, то они вполне могут решить, что менеджеру — плевать на их работу, т.к. он даже разбираться не стал. Это может убить всякую инициативу.
Думаю, что при частом использовании такого трюка возможна докладная начальству от обиженных работников, причём с детальным указанием — какие обязанности он «вследствие своей некомпетентности» перекладывал на волю случая. И оправдаться будет тяжело (хотя, это вполне может быть идеей нового кейса).
Шаг №3 поддерживаю. Мой вариант, помимо него содержал нечто наподобие варианта который предложил tangro, но его вариант мне нравится больше.
Думаю, что при частом использовании такого трюка возможна докладная начальству от обиженных работников, причём с детальным указанием — какие обязанности он «вследствие своей некомпетентности» перекладывал на волю случая. И оправдаться будет тяжело (хотя, это вполне может быть идеей нового кейса).
Шаг №3 поддерживаю. Мой вариант, помимо него содержал нечто наподобие варианта который предложил tangro, но его вариант мне нравится больше.
Странно, что оценивать работу должны были сами работники. Зачем тогда нужен Сергей? Поставить автоматическую монетку и пусть все решения принимает)
Дальше, раз была договоренность о проактивности и оба решения хороши, то логично дать бонус обоим, а задуматься опять же о Сергее, который не в состоянии распределить задачи или о таск-менеджере, в котором не видно, что эта задача уже выполняется другой командой.
Про поддержку опять же — очень странно, что такой вопрос вообще возникает. Написание кода и поддержка суть весь продукт, неотделимы.
В общем, я предлагаю назначить нового руководителя, ну а если Сергей не хочет сам себя менять, то погрязать дальше в некомпетенции руководства, до тех пор, пока проблемы не коснутся уровня руководства выше.
Дальше, раз была договоренность о проактивности и оба решения хороши, то логично дать бонус обоим, а задуматься опять же о Сергее, который не в состоянии распределить задачи или о таск-менеджере, в котором не видно, что эта задача уже выполняется другой командой.
Про поддержку опять же — очень странно, что такой вопрос вообще возникает. Написание кода и поддержка суть весь продукт, неотделимы.
В общем, я предлагаю назначить нового руководителя, ну а если Сергей не хочет сам себя менять, то погрязать дальше в некомпетенции руководства, до тех пор, пока проблемы не коснутся уровня руководства выше.
:) Вопрос был в том, что технически оба решения были примерно одинаковыми. Когда решения технически разные — и это объективно видно, там решение принять обычно не составляет труда.
Ну из поста и кейса не очевидна одинаковость (какие-то метрики, жаркие двухдневные споры).
Плюс ко всему из кейса командам плевать, чье решение будет использоваться — главное, чтобы был плюсик в аттестации и это было оговорено заранее.
А значит, Сергею тут и думать нечего, кроме как «Как я мог допустить, что они занимаются одним и тем же, надо это срочно исправить».
Плюс ко всему из кейса командам плевать, чье решение будет использоваться — главное, чтобы был плюсик в аттестации и это было оговорено заранее.
А значит, Сергею тут и думать нечего, кроме как «Как я мог допустить, что они занимаются одним и тем же, надо это срочно исправить».
Исходя из того что сложность такого рода скриптов должна быть не очень высока, поощрить нужно всех и пусть пользуются каждый своим решением — получаем дополнительную перепроверку, некую соревновательность между командами, ну и у каждой команды автор скриптов всегда рядом.
Хотя на практике подозреваю что выбрал бы решение на перле как на более высокоуровневом языке (если оно конечно написано именно в таком стиле, а не в стиле си), ибо легче поддерживать
Хотя на практике подозреваю что выбрал бы решение на перле как на более высокоуровневом языке (если оно конечно написано именно в таком стиле, а не в стиле си), ибо легче поддерживать
Тоже хотел такой написать. Ресурсов на автоматические тесты обычно много не надо, а лишняя проверка никогда не бывает лишней. Тем более что у каждого языка программирования свои придури.
В той ситуации такое решение, вероятно, не сработало бы. Потому что прогонами тестов и анализом их результатов занимались отдельные люди.
В свободное от работы время дворник Василий был СЕО нулевого алли в Ив-онлайн, общей численностью в четыре с половиной тысячи человек :)
Кстати, меня давно интересует вопрос, а смог ли бы кто нибудь из «профессиональных тренеров» успешно управлять большим алли в евке. Ну или хотя бы небольшой но хорошо координированной компашкой типа RAISA Shield. Тоже, знаете ли, вызов и практика.
Кстати, меня давно интересует вопрос, а смог ли бы кто нибудь из «профессиональных тренеров» успешно управлять большим алли в евке. Ну или хотя бы небольшой но хорошо координированной компашкой типа RAISA Shield. Тоже, знаете ли, вызов и практика.
Может ли хороший спортсмен стать хорошим тренером? Обязательно ли хорошему тренеру быть хорошим спортсменом?.. Сейчас по факту приходится совмещать три деятельности: тренерскую, предпринимательскую и управленческую. Все это в рамках одной компании, которая занимается обучением. И чем дальше этим занимаюсь, тем четче Капитан Очевидность шепчет на ухо, что это абсолютно разные виды деятельности. :)
Можно ли сказать, что при решении любой проблемы нужно держать в уме три вопроса вместо одного?
* собственно решить проблему
* утрясти при этом взаимоотношения людей
* выяснить как сделать, чтобы проблема не повторялась
Или же это скорее частный вариант?
* собственно решить проблему
* утрясти при этом взаимоотношения людей
* выяснить как сделать, чтобы проблема не повторялась
Или же это скорее частный вариант?
Хотя изъяны этих кейсов также очевидны, как изъяны предложенных в статье, но я бы предложил следующий алгоритм:
1. Смержить не скрипты, но критерии оценки эффективности скриптов
2. Разделить бонус в случае, если результаты оценки эффективности будут приблизительно равны
3. Поручить командам поддерживать свои варианты скриптов
4. Постфактум дополнительно премировать команду, реализация которой оказалась более живучей
1. Смержить не скрипты, но критерии оценки эффективности скриптов
2. Разделить бонус в случае, если результаты оценки эффективности будут приблизительно равны
3. Поручить командам поддерживать свои варианты скриптов
4. Постфактум дополнительно премировать команду, реализация которой оказалась более живучей
Мое виденье проблемы относительно Вашего предложенного решения:
1. Выбрать лучшее решение по заданным критериям, а не тем которые придумывают команды. В случае если оба решения прямо одинаково хороши — считать оба решения «лучшими».
2. Оставить поддержку «лучшего» решения. Соответственно, если их два, вот пусть каждая свое решение и поддерживает.
Команды останутся довольны, мы получили разносторонние тесты. Более того мы можем задать направления для дальнейшего развития.
3. Похвалить команду выдавшую «лучшее» решение. Если решения два — то и награды две.*
4. Тут на 100% согласен с Вами. Нужно договорится о том, что бы не повторялось таких ситуация
Примечание.
В зависимости от атмосферы в коллективе, принятых систем наград и финансового состояния компании, возможно, нужно пожурить за возникшую коллизию. Журить нужно человека ответственного за постановку, распределению и учету текущих задач. Либо словами, либо частью бонуса.
И мое мнение — никаких монеток. Цитируя Шекспира с переводе Пастернака: "… Так погибают замыслы с размахом, в начале обещавшие успех..." Я к тому, что видеть, как решается результативность твоей работы монеткой — не самое приятное.
Если я не прав — укажите где, подискутируем.
1. Выбрать лучшее решение по заданным критериям, а не тем которые придумывают команды. В случае если оба решения прямо одинаково хороши — считать оба решения «лучшими».
2. Оставить поддержку «лучшего» решения. Соответственно, если их два, вот пусть каждая свое решение и поддерживает.
Команды останутся довольны, мы получили разносторонние тесты. Более того мы можем задать направления для дальнейшего развития.
3. Похвалить команду выдавшую «лучшее» решение. Если решения два — то и награды две.*
4. Тут на 100% согласен с Вами. Нужно договорится о том, что бы не повторялось таких ситуация
Примечание.
В зависимости от атмосферы в коллективе, принятых систем наград и финансового состояния компании, возможно, нужно пожурить за возникшую коллизию. Журить нужно человека ответственного за постановку, распределению и учету текущих задач. Либо словами, либо частью бонуса.
И мое мнение — никаких монеток. Цитируя Шекспира с переводе Пастернака: "… Так погибают замыслы с размахом, в начале обещавшие успех..." Я к тому, что видеть, как решается результативность твоей работы монеткой — не самое приятное.
Если я не прав — укажите где, подискутируем.
А мне кажется, что менеджер в первую очередь должен не решать «кому и как выдать плюшки», а открыть для себя новую проблему в команде — люди делают какие-то вещи, которые не были заранее запланированы и «проданы» наверх. Возможно, это время можно было потратить на что-то более важное для бизнеса?
С другой, стороны раз люди (да еще и 2 разные команды!) этим занимались, то, скорее всего, автоматизации действительно не хватает.
Значит, можно попробовать вычленить проблему которую пытались решить команды автоматизацией и ОФИЦИАЛЬНО выделить ресурсы для ее решения. При этом к официальному решению проблемы нужно привлечь обе команды (ключевых людей причастных к автоматизации). Если все пройдет хорошо, то в результате обе команды будут довольны тем что их (уже) общее решение теперь выполняется на регулярной основе и выделенном железе, а также получат неоценимый урок о том как правильно продавать идеи наверх чтобы не делать их «втихую» на практике.
С другой, стороны раз люди (да еще и 2 разные команды!) этим занимались, то, скорее всего, автоматизации действительно не хватает.
Значит, можно попробовать вычленить проблему которую пытались решить команды автоматизацией и ОФИЦИАЛЬНО выделить ресурсы для ее решения. При этом к официальному решению проблемы нужно привлечь обе команды (ключевых людей причастных к автоматизации). Если все пройдет хорошо, то в результате обе команды будут довольны тем что их (уже) общее решение теперь выполняется на регулярной основе и выделенном железе, а также получат неоценимый урок о том как правильно продавать идеи наверх чтобы не делать их «втихую» на практике.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О принятии устойчивых решений или кейс-клуб на Хабре