На заводе так работает. В ИТ тоже так - но в суппорте, или любом другом конвейере, где примерно понятно и повторяется деятельность, можно вводить нормы.
Но когда мы говорим о проектах, и проектной деятельности - что составляет львиную долю ИТ, нормы неприменимы. Проект по определению уникален и конечен. Даже если мы в прошлом уже делали аналогичный, условия меняются, команда меняется (даже если тот же состав - она набирает опыт, или забывает прошлый проект). А кроме того он обычно делает какой-то продукт который надо еще и продать на рынке, который быстро и непредсказуемо меняется.
Именно исходя из этого так все заморачиваются с оценкой, спрашивают исполнителей, перепроверяют и т.д. потому что делается что-то уникальное, что до этого не делали, или делали но не так, и не там, и вообще для другой цели.
Почему не стоит выделять аналитиков в отдельную команду?
Потому что команда, как единое целое должна обладать всеми необходимыми навыками для поставки результата (инкремента). Отдельная команда аналитиков, как результат даст сводки. А цель не сводки, а продукт, который можно заделиверить. Такая философия.
Можно уточнить, как на практике разрешается конфликт того, что команда двигается к цели спринта, а аналитик в теории прорабатывается задачи на будущее? Насколько аналитик нужен непосредственно в команде вместе с разработчиками?
Аналитика тоже часть работы, она включается в цель. Работа над бэклогом ведется постоянно, поэтому аналитик вполне себе вписывается — он может работать в том числе на продакт оунера, помогать ему готовиться к будущим спринтам. Ведь сказано что скрам контейнер — все что в гайде должно быть, остальное на усмотрение конкретной организации. Плюс ПО может делегировать ряд задач — как раз вот аналитику.
Как я понимаю главный вопрос почему аналитик должен быть в команде разработчиков, а не в отдельно специализированной — как выше сказал чтоб он работал на общий результат, а не выдавал свой анализ как результат а дальше хоть трава не расти. Все должны быть вовлечены в построение продукта, городить дополнительную функциональную иерархию, в виде аналитических команд, QA команд и т.д. — есть создавать препятствия и внутренние противоречия. Но эт опять же суха теория — на практике по разному бывает — у меня был опыт специализированных мини команд внутри скрам тима, но все равно они работали на общую цель.
самоуправляющиеся )) в новой версии
Во мне просто заговорил здравый смысл и жизненный опыт — не могут 80 людей сами взять и сформировать команды) Даже если им такое право предоставят — все равно появятся лидеры которые начнут формировать эти команды. Так не лучше то же самое делать сразу а не ждать пока они появятся? Это все таки не детский сад.
На этом собственно я и прокололся )
а так да согласен — большую часть списка я собственно проштудировал внимательнейшим образом, и это помогло.
изучал — но у меня возник вопрос стоит ли оно временных затрат? Учитывая что я не собираюсь становиться agile-коучем.
Как показал лично мой пример, никому не навязываю — можно обойтись и без книжек.
проект, это форма деятельности, которая имеет точку старта и точку завершения. Важно отличать это, так как люди начнут потом относить проект ко всему подряд: компании, продукту, не дай бог — процессу.
Думаю одно не исключает другое, потому и привел матричные организационные структуры.
По-другому, когда в проекте появляется долгострой, то самого погруженного называют productом
Я бы поправил — что не самого погруженного, а того кто отвечает за него. Тут разные истории в продуктовых компания а-ля яндекс, и в аутсорсинге где клепают что-то для заказчиков.
Любопытно )
То есть берем два абстрактных понятия — которые означают разное. Люди их допустим путают, какая-то часть. И мы вот вообще никогда не пишем ничего о том в чем разница между ними? Мотивируя это тем что вот из-за того что мы пишем — они еще больше путают?)
Я вроде достаточно внятно выше объяснил свою мотивацию — многие путают. И даже те кто не путают — не все способны объяснить в чем реально разница. Я разжевал.
То есть есть вопрос, есть путаница — я ее разъясняю приправляя своим мнением и опытом. В чем ваш вопрос? Что не надо этим необразованным объяснять такую элементарщину, еще больше путаться будут, тёмные? ) Я предпочитаю не быть снобом а наоборот делиться, и исходить из того что все люди разные и то что очевидно нам с вами, неочевидно другим — особенно представителям профессий далеких от этого.
То что одно без другого не существует это понятно. Лично для меня и в рамках IT — продукт интереснее тем что операционка с годами надоедает, есть интерес развивать, созидать, а не заниматься задачами, календарными планами, критическими путями. Зависит конечно и от масштабов.
В вашей парадигме это скорее инвесторы решают на чем фокус, то есть определяют тот же треугольник деньги — качество — время, в его рамках проставляют акценты. Я с более приземленной точки зрения наверное рассуждаю — что вот допустим мы уже знаем что сказали инвесторы, нам надо определить как позицию назвать чтоб это было правильно и отражало суть.
А насчет более интересное — спорю ) но тут кому что по душе, разные профессии хоть и часто из одной переходят в другую.
Для меня это тоже очевидно, но я в последние несколько месяцев во-первых видел людей которые плавают в этих понятиях. Во-вторых мне этот вопрос раз 5 задали на собеседованиях, и потом уточнили что многие мои коллеги на этом вопросе сыпались.
Поэтому решил поделиться — как минимум из моего личного опыта ряду товарищей описанные вещи совсем неочевидны.
А вы статью то прочитали? Я в первых абзацах как раз объяснил что это как вы выражаетесь «теплое» и «мягкое», и почему. Связь понятий я также объяснил. Вы не согласны? Аргументируйте.
Чтобы изучить человека и действительно его понимать, нужно прожить с ним в одной комнате несколько лет и то гарантий нет.
И это повод не изучать его совсем? Серьезно? Как-то похоже на из крайности в крайность. Ваши вопросы — это не изучение и не оптимизация.
Какой мотор под капотом — не важно, важно сколько он потребляет, какой интервал обслуживания и какая вероятность отказа.
Узко. Когда вы знаете интервал и вероятность — вы знаете только это. Когда вы знаете свойства мотора — вы можете сопоставить какие-то события, со этими свойствами — сделать вывод, построить взаимосвязь — быстрее понять вещи. Мне странно вам это объяснять. Это элементарно. По этой же причине най войне существует разведка. Как вы вообще можете работать с человеком ничего про него не зная?
Риски возникают, когда процессы устроены так криво, что от конкретной персоналии многое зависит. Однако это причина не биографии изучать, а перестроить процессы, только так вы сможете действительно снизить риски, а не заниматься самообманом.
От конкретных персоналий всегда много зависит — потому что именно они выполняют работу. Не доверяете им — делаете сами. Даже если немногое — все равно риски есть.
В том то и дело что человек не функция. Он более многогранен. Вы очень упрощаете — в системе не один процесс. Есть процесс, есть исполнители, есть руководители, и все они влияют на результат. Из ваших слов — если результата нет в любом случае кривой процесс, а другие участники по боку? Вам самим не кажется это странным?
Ни один процесс идеальным не будет, и риски все не закроет. Вы просто не знаете что может произойти и с кем — то есть с исполнителями, а также со средой. Это неопределенность. Ни один процесс неопределенность не закроет. И в критической ситуации (да и не только в критической) — важнее кто рядом с вами и как они себя проявят, чем то как вы прописали им регламенты. Даже проще скажу — в жизни часто что-то идет не так, в проектной деятельности особенно, да и в функциональной тоже. И в этой ситуации ваш процесс летит в мусорку. И функции тоже. Остаются люди которые либо что-то делают либо сливаются. Именно поэтому их надо изучать и понимать.
В целом мне кажется вы уже просто защищаете свою концепцию во что бы то ни стало. Поэтому думаю на том можно закрыть дискуссию — вы высказали свое мнение, я свое. Ваша аргументация по мне — несостоятельна, местами утопична. Ваше мнение про мою можете описать — можете оставить при себе. Удачи.
Ну да ) половина работодателей нанимает функцию а не человека. Тогда конечно неважно. Только мне кажется это не то что неправильно — это глупо. Человек сложен, всегда, у него было детство юность, опыт, воспитание, образование. Все влияет на него. Не изучать это как-то странно. Считать что это никак не повлияет на его работу — ошибочно. Это формирует его работу в целом, от начала до конца.
Вы говорите что вам не важно какой мотор под капотом лишь бы ехала быстро — примерно так. Эти вещи взаимосвязаны. Биография именно потому и изучается — что формирует поведение человека.
Подходя ситуативно, вы упускаете из виду очень много вещей, а именно рисков или потенциал человека. Это не станок который в рамках ресурса будет стабильно выполнять свою работу с прописанным уровнем качества учитывая износ. С людьми совсем не так, они намного сложнее. А вы даже список уже сделанного ими — не хотите читать.
Ну так в чем проблема биографическую информацию черпать из резюме?
Суть вопросов мне кажется момент ключевой — поэтому я остановился на этом подробнее.
Факт присутствия в целом вопросов — имхо не новость, а реальность. Давным давно серьезные компании просят Cover Letter, и добавляют к ним еще вопросы. То есть лично мне непонятна явная претензия на инновацию поста.
Вопросы хорошая практика — это первичный скрининг, его часто используют, чтоб не тратить своё время и время кандидата на собеседование когда по ключевым моментам не сходятся. Но не те что вы перечислили.
Я бы оставил только конкретику про фреймворки которые вам нужны. Остальное это очень размытое, шаблонное — которое даже открытые кандидаты не захотят делать, потому что надоели все с одними и теми же вопросами, оторванными от контекста. Нельзя рассказать что интересно, не выставив какие-то рамки контекста и не рассказав про свой путь.
А для этого нужно резюме. А вы предлагаете тоже самое только в формате наратива и с бОльшими подробностями. Но без технических деталей в виде четкой хронологии например.
К чему противопоставление резюме? Вы в целом неверно понимаете его цель. Оно не должно отвечать на вопросы. Поэтому я собственно согласен что вопросы нужны.
Резюме основа — послужной список. Руководителю надо понимать что за человек, что делал, где учился, просто как нулевая стадия, база. Просто чтоб понимать контекст. Без контекста ответы на ваши вопросы будут бесполезны — ведь там может быть не указана последовательность, даты, нюансы. Вам придется спрашивать на собеседовании — а когда это было? А что было до этого, а потом? А как? Та же самая потеря времени. И с высокой вероятностью там будет все очень приукрашено.
Далее — чтоб ответить хорошо на примеры ваших вопросов, нужно уметь писать. Вы много айти-спецов знаете с хорошими навыками копирайтинга? Исключая тех у кого это часть работы — это непрофильная деятельность, они последний раз такие сочинения в школе писали. Да кстати, эта писанина вообще никакого отношения не имеет к софт-скиллам. Писать и говорить это разное. Выстаивать отношения с кем-либо — вообще из другой оперы.
Мое мнение — вы изобретаете велосипед. И вы давно не были в роли кандидата по ощущениям. А многие специалисты просто избалованы вниманием со стороны работодателей, что им лень даже резюме свое написать (2 страницы).
Именно из этих соображений — я описал какие проекты имею в виду. Энтерпрайз согласен — достаточно своеобразен, и отличается от пользовательских проектов.
Но мне кажется что обсуждение именно PM не совсем верно, и сужать тему только до IT-сегмента не совсем то, что нужно для поиска решение.
Просто лично меня, как работающего давно в этой сфере — интересует именно в разрезе IT. Плюс думаю от отрасли все таки многое зависит — менеджмент проектов он очень разный, в IT он особенно своеобразный.
В целом я с вами согласен, придерживаюсь той же позиции. Единственное — аналогия проект/отдела не совсем правильно, это все же разные сущности, и функциональный руководитель и руководитель проекта имеют свою специфическую составляющую, в первую очередь тот факт что проект подразумевает наличие высокого уровня неопределенности. Но в остальном да — те и те руководители со всеми вытекающими.
На заводе так работает. В ИТ тоже так - но в суппорте, или любом другом конвейере, где примерно понятно и повторяется деятельность, можно вводить нормы.
Но когда мы говорим о проектах, и проектной деятельности - что составляет львиную долю ИТ, нормы неприменимы. Проект по определению уникален и конечен. Даже если мы в прошлом уже делали аналогичный, условия меняются, команда меняется (даже если тот же состав - она набирает опыт, или забывает прошлый проект). А кроме того он обычно делает какой-то продукт который надо еще и продать на рынке, который быстро и непредсказуемо меняется.
Именно исходя из этого так все заморачиваются с оценкой, спрашивают исполнителей, перепроверяют и т.д. потому что делается что-то уникальное, что до этого не делали, или делали но не так, и не там, и вообще для другой цели.
Аналитика тоже часть работы, она включается в цель. Работа над бэклогом ведется постоянно, поэтому аналитик вполне себе вписывается — он может работать в том числе на продакт оунера, помогать ему готовиться к будущим спринтам. Ведь сказано что скрам контейнер — все что в гайде должно быть, остальное на усмотрение конкретной организации. Плюс ПО может делегировать ряд задач — как раз вот аналитику.
Как я понимаю главный вопрос почему аналитик должен быть в команде разработчиков, а не в отдельно специализированной — как выше сказал чтоб он работал на общий результат, а не выдавал свой анализ как результат а дальше хоть трава не расти. Все должны быть вовлечены в построение продукта, городить дополнительную функциональную иерархию, в виде аналитических команд, QA команд и т.д. — есть создавать препятствия и внутренние противоречия. Но эт опять же суха теория — на практике по разному бывает — у меня был опыт специализированных мини команд внутри скрам тима, но все равно они работали на общую цель.
Во мне просто заговорил здравый смысл и жизненный опыт — не могут 80 людей сами взять и сформировать команды) Даже если им такое право предоставят — все равно появятся лидеры которые начнут формировать эти команды. Так не лучше то же самое делать сразу а не ждать пока они появятся? Это все таки не детский сад.
На этом собственно я и прокололся )
а так да согласен — большую часть списка я собственно проштудировал внимательнейшим образом, и это помогло.
Там вопросы больше были про то как их сформировать — дать людям самим распределиться, или же распределять своей властью.
изучал — но у меня возник вопрос стоит ли оно временных затрат? Учитывая что я не собираюсь становиться agile-коучем.
Как показал лично мой пример, никому не навязываю — можно обойтись и без книжек.
Думаю одно не исключает другое, потому и привел матричные организационные структуры.
Я бы поправил — что не самого погруженного, а того кто отвечает за него. Тут разные истории в продуктовых компания а-ля яндекс, и в аутсорсинге где клепают что-то для заказчиков.
но вообще объяснение мне нравится — возьму на вооружение. Спасибо )
То есть берем два абстрактных понятия — которые означают разное. Люди их допустим путают, какая-то часть. И мы вот вообще никогда не пишем ничего о том в чем разница между ними? Мотивируя это тем что вот из-за того что мы пишем — они еще больше путают?)
Я вроде достаточно внятно выше объяснил свою мотивацию — многие путают. И даже те кто не путают — не все способны объяснить в чем реально разница. Я разжевал.
То есть есть вопрос, есть путаница — я ее разъясняю приправляя своим мнением и опытом. В чем ваш вопрос? Что не надо этим необразованным объяснять такую элементарщину, еще больше путаться будут, тёмные? ) Я предпочитаю не быть снобом а наоборот делиться, и исходить из того что все люди разные и то что очевидно нам с вами, неочевидно другим — особенно представителям профессий далеких от этого.
А насчет более интересное — спорю ) но тут кому что по душе, разные профессии хоть и часто из одной переходят в другую.
Поэтому решил поделиться — как минимум из моего личного опыта ряду товарищей описанные вещи совсем неочевидны.
И это повод не изучать его совсем? Серьезно? Как-то похоже на из крайности в крайность. Ваши вопросы — это не изучение и не оптимизация.
Узко. Когда вы знаете интервал и вероятность — вы знаете только это. Когда вы знаете свойства мотора — вы можете сопоставить какие-то события, со этими свойствами — сделать вывод, построить взаимосвязь — быстрее понять вещи. Мне странно вам это объяснять. Это элементарно. По этой же причине най войне существует разведка. Как вы вообще можете работать с человеком ничего про него не зная?
От конкретных персоналий всегда много зависит — потому что именно они выполняют работу. Не доверяете им — делаете сами. Даже если немногое — все равно риски есть.
В том то и дело что человек не функция. Он более многогранен. Вы очень упрощаете — в системе не один процесс. Есть процесс, есть исполнители, есть руководители, и все они влияют на результат. Из ваших слов — если результата нет в любом случае кривой процесс, а другие участники по боку? Вам самим не кажется это странным?
Ни один процесс идеальным не будет, и риски все не закроет. Вы просто не знаете что может произойти и с кем — то есть с исполнителями, а также со средой. Это неопределенность. Ни один процесс неопределенность не закроет. И в критической ситуации (да и не только в критической) — важнее кто рядом с вами и как они себя проявят, чем то как вы прописали им регламенты. Даже проще скажу — в жизни часто что-то идет не так, в проектной деятельности особенно, да и в функциональной тоже. И в этой ситуации ваш процесс летит в мусорку. И функции тоже. Остаются люди которые либо что-то делают либо сливаются. Именно поэтому их надо изучать и понимать.
В целом мне кажется вы уже просто защищаете свою концепцию во что бы то ни стало. Поэтому думаю на том можно закрыть дискуссию — вы высказали свое мнение, я свое. Ваша аргументация по мне — несостоятельна, местами утопична. Ваше мнение про мою можете описать — можете оставить при себе. Удачи.
Вы говорите что вам не важно какой мотор под капотом лишь бы ехала быстро — примерно так. Эти вещи взаимосвязаны. Биография именно потому и изучается — что формирует поведение человека.
Подходя ситуативно, вы упускаете из виду очень много вещей, а именно рисков или потенциал человека. Это не станок который в рамках ресурса будет стабильно выполнять свою работу с прописанным уровнем качества учитывая износ. С людьми совсем не так, они намного сложнее. А вы даже список уже сделанного ими — не хотите читать.
Суть вопросов мне кажется момент ключевой — поэтому я остановился на этом подробнее.
Факт присутствия в целом вопросов — имхо не новость, а реальность. Давным давно серьезные компании просят Cover Letter, и добавляют к ним еще вопросы. То есть лично мне непонятна явная претензия на инновацию поста.
Я бы оставил только конкретику про фреймворки которые вам нужны. Остальное это очень размытое, шаблонное — которое даже открытые кандидаты не захотят делать, потому что надоели все с одними и теми же вопросами, оторванными от контекста. Нельзя рассказать что интересно, не выставив какие-то рамки контекста и не рассказав про свой путь.
А для этого нужно резюме. А вы предлагаете тоже самое только в формате наратива и с бОльшими подробностями. Но без технических деталей в виде четкой хронологии например.
К чему противопоставление резюме? Вы в целом неверно понимаете его цель. Оно не должно отвечать на вопросы. Поэтому я собственно согласен что вопросы нужны.
Резюме основа — послужной список. Руководителю надо понимать что за человек, что делал, где учился, просто как нулевая стадия, база. Просто чтоб понимать контекст. Без контекста ответы на ваши вопросы будут бесполезны — ведь там может быть не указана последовательность, даты, нюансы. Вам придется спрашивать на собеседовании — а когда это было? А что было до этого, а потом? А как? Та же самая потеря времени. И с высокой вероятностью там будет все очень приукрашено.
Далее — чтоб ответить хорошо на примеры ваших вопросов, нужно уметь писать. Вы много айти-спецов знаете с хорошими навыками копирайтинга? Исключая тех у кого это часть работы — это непрофильная деятельность, они последний раз такие сочинения в школе писали. Да кстати, эта писанина вообще никакого отношения не имеет к софт-скиллам. Писать и говорить это разное. Выстаивать отношения с кем-либо — вообще из другой оперы.
Мое мнение — вы изобретаете велосипед. И вы давно не были в роли кандидата по ощущениям. А многие специалисты просто избалованы вниманием со стороны работодателей, что им лень даже резюме свое написать (2 страницы).
Любопытно, но бизнес модель и модель монетизации это несколько разное, название вводит в заблуждение.
Просто лично меня, как работающего давно в этой сфере — интересует именно в разрезе IT. Плюс думаю от отрасли все таки многое зависит — менеджмент проектов он очень разный, в IT он особенно своеобразный.
В целом я с вами согласен, придерживаюсь той же позиции. Единственное — аналогия проект/отдела не совсем правильно, это все же разные сущности, и функциональный руководитель и руководитель проекта имеют свою специфическую составляющую, в первую очередь тот факт что проект подразумевает наличие высокого уровня неопределенности. Но в остальном да — те и те руководители со всеми вытекающими.