У грамотно выстроенного процесса есть важное качество — его можно масштабировать, в этом случае речь начинает идти уже о наборе практик, а не о конкретной ситуации. Масштабировать описанное в статье нельзя, и на месте автора гордиться описанной в статье ПРОБЛЕМОЙ другой руководитель не стал бы. Уже от смены 1-2 игроков такой отдел начнёт трясти. А автору скорее просто повезло собрать вокруг себя людей со схожими принципами, но которым при этом до реального (ну не всю же жизнь работать на одном заводе) роста дела нет. Как для развития экономики необходима небольшая инфляция, так и для развития коллектива необходима свежая кровь. Вангую, что если бы автор остался на прежнем месте, то за короткий срок окончательно превратил бы свой отдел в сборище смотрящих на всех свысока консервативных, грызущихся "против всех" и боящихся потерять насиженное место профессионалов средней руки, ведь, собственно, о своём взаимоотношении с соседними отделами также было написано. Это вообще добило. Руководитель обязан задумываться не только о себе и своих людях, но и о бизнесе. И если у других отделов есть необходимость в участии специалистов с твоей стороны, это повод поговорить с руководителями соседних направлений, но все же не просто отвечать, что в выходные мы не работаем, ведь так можно и контракт дорогой сорвать. Нельзя жить по принципу "моя хата с краю" и гордиться этим.
Снимаю шляпу, если все описанное в статье — ваши реальные практики, особенно, если они развивались в тот вид, что есть сейчас, с 2016 года. Как работаете с мотивацией относительно обмена знаниями? Ведь Колей, к сожалению, является далеко не каждый сотрудник.
А потом оказывается, что арбуз должен обладать совершенно другими свойствами и… "Аааа! Нам нужно менять методологию оценки задач!", и вообще "Кто посмел уточнить требования?"
Для Вас, как для представителя со стороны бизнеса, смысл "киллер-фич" в Вашем позиционировании и отстройке от конкурентов, в конечном результате — в увеличении количества пользователей за счёт удобного функционала. Для меня же, как для потенциального пользователя Вашего продукта, больший интерес представляла бы статья, посвящённая конкретным "фишкам" Вашей системы: "есть вот такая проблема, мы предлагаем решать её вот этим способом, потому что это удобно и экономит n времени", собственно, об этом я и написал. В любом случае, Ваши клиенты будут голосовать за Ваш продукт рублём, а мне так и не понятен смысл Вашей статьи в том виде, а котором она была опубликована. Всё же это профильная площадка.
Извините, но "киллер-фичи" Вашего продукта не увидел. Я плохо смотрел или Вы просто запостили на профильный ресурс стандартный текст из корпоративного блога?
Благодарю за Ваш ответ. В любом случае, Вы каким-то образом используете полученные сведения, хотя бы с целью скорректировать управление, вряд ли этот хелсчек отправляется "в стол" (хотя я и не исключаю пользу практики просто дать людям выговориться), так что я имею в виду как раз те моменты со стороны сотрудников, когда определённый выданный показатель самооценки команды приводит к конкретным изменениям через какой-то промежуток времени, с какой стороны ни смотри, а этот показатель — тоже kpi, который люди могут сознательно подкручивать. Что же, рад, если у вас это не так.
Если исходить из предпосылки, что подобные вопросы задаются с чётким пониманием их сути, то да, смеяться и в цирке не захочется. Не будем поднимать вопрос, стоит ли вообще идти линейным руководителем в компанию, с серьёзным лицом проводящую подобный отсев, это уже личный выбор каждого, да и может оказаться для кого-то неплохим опытом. Если же принять за истину, что руководитель проекта должен беседовать непосредственно с топами, цель которых — найти подходящего человека, а следовательно они с радостью ответят на вопросы о принятых процессах, да и сами по заданным со стороны соискателя вопросам смогут сформировать первичное впечатление, то ситуация будет выглядеть уже не такой безрадостной.
Спасибо за статью, но у меня сразу возникла пара вопросов. 1. Каков средний срок работы сотрудника в компании? Успеваете ли растить кадры, не уходят ли слишком быстро на сторону прокачанные спецы? 2. Как боретесь с таким проявлением "тёмной стороны", как нежелание лидов брать себе конкурентов, а, следовательно, низким качеством потока людей с найма?
Очень познавательно. Как боретесь со злоупотреблениями со стороны участников, когда команда на N-й раз начинает манипулировать результатами с целью получить тот или иной профит от руководства или начинает пытаться переключить менеджерское внимание на надуманные проблемы, отвлекая от реальных косяков?
Спасибо за статью. Согласен с автором, однако упущен важный момент в той части, где говорится о реализующих проект подрядчиках — на любой конкурс, на любую заказную разработку всегда найдётся куча компаний, бьющих себя пяткой в грудь, однако на деле слабо представляющих себе не только цели проекта (это на деле вообще важно мало кому "по ту сторону" контракта), но и вообще возможность его реализации, откровенно некомпетентных, но умеющих себя грамотно продать. Поэтому хорошо бы заранее иметь некий набор фильтров, позволяющих отсечь "левых" исполнителей (причём размер и известность подрядчика здесь не играют роли). Я уже молчу про нюансы закупок в виде откатов линейным менеджерам заказчика…
Мне нравится Ваша постановка вопроса и тонкий сарказм :) Но все же отвечу, что безусловно только служба такси, а водители и машины — ресурсы. Если набрать больше водителей, которые будут лучше возить и ездить на современных автомобилях, то заказов от этого больше не станет, потому что массово никто об этом не узнает, а за время распространения информации по сарафанному радио соседняя служба такси вложится в маркетинг аналогичного сервиса, куда, кстати, и уйдут водители, причём достаточно быстро.
Прспорю с Вами. Все гибкие методологии разработки как раз направлены на обеспечение большей лёгкости внесения изменений в продукт, чтобы продавать не то, что делают разработчики, а чтобы разрабатывалось то, что продаётся и нужно конечному клиенту.
У грамотно выстроенного процесса есть важное качество — его можно масштабировать, в этом случае речь начинает идти уже о наборе практик, а не о конкретной ситуации. Масштабировать описанное в статье нельзя, и на месте автора гордиться описанной в статье ПРОБЛЕМОЙ другой руководитель не стал бы. Уже от смены 1-2 игроков такой отдел начнёт трясти. А автору скорее просто повезло собрать вокруг себя людей со схожими принципами, но которым при этом до реального (ну не всю же жизнь работать на одном заводе) роста дела нет. Как для развития экономики необходима небольшая инфляция, так и для развития коллектива необходима свежая кровь. Вангую, что если бы автор остался на прежнем месте, то за короткий срок окончательно превратил бы свой отдел в сборище смотрящих на всех свысока консервативных, грызущихся "против всех" и боящихся потерять насиженное место профессионалов средней руки, ведь, собственно, о своём взаимоотношении с соседними отделами также было написано. Это вообще добило. Руководитель обязан задумываться не только о себе и своих людях, но и о бизнесе. И если у других отделов есть необходимость в участии специалистов с твоей стороны, это повод поговорить с руководителями соседних направлений, но все же не просто отвечать, что в выходные мы не работаем, ведь так можно и контракт дорогой сорвать. Нельзя жить по принципу "моя хата с краю" и гордиться этим.
Снимаю шляпу, если все описанное в статье — ваши реальные практики, особенно, если они развивались в тот вид, что есть сейчас, с 2016 года. Как работаете с мотивацией относительно обмена знаниями? Ведь Колей, к сожалению, является далеко не каждый сотрудник.
А как решали вопрос с соседями? В процессе работы все же дыма много вытягивается на улицу прямо с Вашего балкона :)
Буду Вам благодарен, это очень интересный для меня вопрос! Спасибо!
Не могли бы Вы также немного рассказать как закладываете в проект бюджет на участие TSA и как обосновываете это перед заказчиком?
А потом оказывается, что арбуз должен обладать совершенно другими свойствами и… "Аааа! Нам нужно менять методологию оценки задач!", и вообще "Кто посмел уточнить требования?"
А потом появится открытый платный API и совсем некуда будет скрыться от автообзвонщиков на базе этой технологии :(
Вы опубликовали информацию в публичном пространстве и получили на неё фидбек, давайте относится к этому спокойнее. Спасибо.
Для Вас, как для представителя со стороны бизнеса, смысл "киллер-фич" в Вашем позиционировании и отстройке от конкурентов, в конечном результате — в увеличении количества пользователей за счёт удобного функционала. Для меня же, как для потенциального пользователя Вашего продукта, больший интерес представляла бы статья, посвящённая конкретным "фишкам" Вашей системы: "есть вот такая проблема, мы предлагаем решать её вот этим способом, потому что это удобно и экономит n времени", собственно, об этом я и написал. В любом случае, Ваши клиенты будут голосовать за Ваш продукт рублём, а мне так и не понятен смысл Вашей статьи в том виде, а котором она была опубликована. Всё же это профильная площадка.
Извините, но "киллер-фичи" Вашего продукта не увидел. Я плохо смотрел или Вы просто запостили на профильный ресурс стандартный текст из корпоративного блога?
Благодарю за Ваш ответ. В любом случае, Вы каким-то образом используете полученные сведения, хотя бы с целью скорректировать управление, вряд ли этот хелсчек отправляется "в стол" (хотя я и не исключаю пользу практики просто дать людям выговориться), так что я имею в виду как раз те моменты со стороны сотрудников, когда определённый выданный показатель самооценки команды приводит к конкретным изменениям через какой-то промежуток времени, с какой стороны ни смотри, а этот показатель — тоже kpi, который люди могут сознательно подкручивать. Что же, рад, если у вас это не так.
Если исходить из предпосылки, что подобные вопросы задаются с чётким пониманием их сути, то да, смеяться и в цирке не захочется. Не будем поднимать вопрос, стоит ли вообще идти линейным руководителем в компанию, с серьёзным лицом проводящую подобный отсев, это уже личный выбор каждого, да и может оказаться для кого-то неплохим опытом. Если же принять за истину, что руководитель проекта должен беседовать непосредственно с топами, цель которых — найти подходящего человека, а следовательно они с радостью ответят на вопросы о принятых процессах, да и сами по заданным со стороны соискателя вопросам смогут сформировать первичное впечатление, то ситуация будет выглядеть уже не такой безрадостной.
Спасибо за статью, но у меня сразу возникла пара вопросов. 1. Каков средний срок работы сотрудника в компании? Успеваете ли растить кадры, не уходят ли слишком быстро на сторону прокачанные спецы? 2. Как боретесь с таким проявлением "тёмной стороны", как нежелание лидов брать себе конкурентов, а, следовательно, низким качеством потока людей с найма?
Очень познавательно. Как боретесь со злоупотреблениями со стороны участников, когда команда на N-й раз начинает манипулировать результатами с целью получить тот или иной профит от руководства или начинает пытаться переключить менеджерское внимание на надуманные проблемы, отвлекая от реальных косяков?
Спасибо за статью. Согласен с автором, однако упущен важный момент в той части, где говорится о реализующих проект подрядчиках — на любой конкурс, на любую заказную разработку всегда найдётся куча компаний, бьющих себя пяткой в грудь, однако на деле слабо представляющих себе не только цели проекта (это на деле вообще важно мало кому "по ту сторону" контракта), но и вообще возможность его реализации, откровенно некомпетентных, но умеющих себя грамотно продать. Поэтому хорошо бы заранее иметь некий набор фильтров, позволяющих отсечь "левых" исполнителей (причём размер и известность подрядчика здесь не играют роли). Я уже молчу про нюансы закупок в виде откатов линейным менеджерам заказчика…
Потому Вы и выделили капсом слово ПРАВИЛЬНОЕ :)
Мне нравится Ваша постановка вопроса и тонкий сарказм :) Но все же отвечу, что безусловно только служба такси, а водители и машины — ресурсы. Если набрать больше водителей, которые будут лучше возить и ездить на современных автомобилях, то заказов от этого больше не станет, потому что массово никто об этом не узнает, а за время распространения информации по сарафанному радио соседняя служба такси вложится в маркетинг аналогичного сервиса, куда, кстати, и уйдут водители, причём достаточно быстро.
Хорошо бы ещё при этом не превратить agile в круговую поруку, к чему у нас склонны.
Прошу прощения за опечатку.
Прспорю с Вами. Все гибкие методологии разработки как раз направлены на обеспечение большей лёгкости внесения изменений в продукт, чтобы продавать не то, что делают разработчики, а чтобы разрабатывалось то, что продаётся и нужно конечному клиенту.