Вода и ничего кроме воды, ведь фактически вся статья — о недоверии к собственным сотрудникам. Гаденькое впечатление. Удалённую работу и взаимодействие нужно уметь правильно "готовить". Большинство моих личных ошибок на первом этапе, когда я только начинал руководить географически распределенной командой, была связана как раз с попытками контролировать каждый шаг, что выливалось в демотивацию сотрудников и совершенно дурацкий микроменеджмент. Хотя до трекеров экрана я и не опускался никогда. К счастью, я сумел это достаточно быстро побороть и сделал следующие выводы на основе успешного уже опыта. Во-первых, удаленка действительно подходит не всем. Для неё нужно уметь нанимать правильных людей. Во-вторых, нужно задуматься о правильной мотивации. И я сейчас не про распевание гимнов. Человек, в первую очередь, должен получать конкурентоспособную зарплату, это необходимо, ведь тогда человек будет держаться за место, где предлагают комфортные условия труда за достойный прайс, а после этого необходимо уже объединить людей общей целью, ненавязчиво погружать их в суть происходящих процессов, для чего необходимо открытое обсуждение любых вопросов (для этого прекрасно подходят рабочие чаты, главное, не требуйте ответа в ту же секунду). Обязательные общие митинги достаточно проводить раз в неделю. В-третьих, доверяйте, наконец, сотрудникам! Контролируйте результат, а не процесс. Так пользы больше будет и для бизнеса, и для сотрудников. Вы наняли правильных людей, серьёзно. А если нет, то, в-четвёртых, направляйте слабого игрока в нужное русло, а если это не помогает, то не бойтесь расстаться с ним. Главное сделать это таким образом, чтобы остальные участники команды не воспринимали это как угрозу "следующим могу стать я". И, в-пятых, самое главное — руководитель распределенной команды должен сам быть сверхорганизован, быть вовлечен во все процессы и доступен максимальное количество времени, удалённая работа не допускает отсроченной обратной связи.
Спасибо за статью. Очевидно, что речь идёт не о "рабочих группах", формируемых краткосрочно, где главная цель — скорость, а о формировании команды для долгосрочной работы. Считаете ли Вы, что любая подобная команда должна подбираться с учётом психотипа участников? Насколько на Ваш взгляд это вообще реально с учётом имеющегося "кадрового голода"?
С большим уважением отношусь к проектам, которые в качестве одной из своих целей ставят повышение качества жизни, создание более комфортной среды или расширение возможностей людей с особыми потребностями. А есть ли у Вас программы, оптимизированные для работы со слабовидящими и незрячими учениками?
ваш комментарий аналогично в таком случае, аргументы?
Вести спор на подобном уровне общения близком к киданию в оппонента собственными экскрементами смысла не вижу, Вы в очередной раз выставляете себя в невыгодном свете, не более. Впрочем, решать Вам. Что касается аргументации — я её привёл, это моё мнение, подкрепленное определённым опытом, не более, чем и Ваше.
нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
Неплохая попытка воззвать к сообществу, обозначив свою принадлежность к "клубу", но нет.
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте
Во-первых, я писал не "называете дураками", а "считать людей дураками", во-вторых все есть в Вашем тексте и комментариях.
профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы
огромная часть провалов в бизнесе в целом — это плохое руководство
когда команда токсична и в целом враждебна, а начальству все равно
И так далее. Но продолжим.
Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
Тонкий укол, не правда ли? Но правда в том, что на любую проблему есть несколько точек зрения, одна и та же ситуация будет по-разному восприниматься разными людьми. Я рад, что Вы считаете мою точку зрения спорной. Это означает, что я сумел донести именно то, что хотел, именно то, что вызывает у Вас несогласие.
Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами?
Ваша статья же о менеджерах проектов, разве нет? И все обсуждение было об управлении. Не передергивайте, пожалуйста.
Не условных. Почему нафиг?
Потому что нечего делать на менеджерских позициях, которые предполагают управление, человеку, который хочет
В целом имхо нужно строить иерархию — если есть ПМ, то его нужно подобрать хорошо и дать ему полномочия руководить. И команде объяснить что вот ваш новый ПМ, любить, жаловать и делать таски.
Нет, вероятно, Вы поняли меня ошибочно. Я имею в виду, что никому не нужен специалист, неспособный организовать работу и коммуникацию внутри/с собственной командой, а претендующий лишь на администрирование уже выстроенных процессов, при этом ещё желающий чтобы его собственный авторитет был навязан "сверху".
Спасибо за статью. Метод практически легко реализуемый и удобный, но вставлю все же свои 5 копеек: документ, а также любая таск- или crm- системы на практике удобнее для менеджеров, которые не используют в своей работе системы контроля версий. Я, все же, в том лагере, который предложит оставить привычные инструменты. Git — разработчикам, jira — управленцам. Но Ваш способ хорош.
Не буду утомлять Вас и читателей очередным длинным комментарием, поэтому отвечу кратко: первое, вся Ваша статья и есть бесконечное нытье о несправедливости мира; второе, считать людей дураками
основываясь лишь на несовпадении ценностей и мифических "недочетах" характеризует глупо только Вас; в-третьих, вот это все "профессионалу с такими работать не захочется" — нафиг таких условных "профессионалов", за которых все сделать надо в организационном плане.
gleb_l Это действительно интересный феномен психологии разработчиков: люди, которые привыкли знать что-то одно глубоко часто либо чувствуют себя экспертами во всех областях сразу (к счастью, встречается крайне редко), либо игнорируют экспертизу в тех областях знаний, от которых далеки (часто). Как Вы лично предпочитаете доносить ценность?
Прикрывать нужно тех, кто приносит пользу, которая не очевидна для вышестоящих. А остальных по ситуации — возможно, что нужно так же легко увольнять, как и прикрывать. Не стоит вести слишком много игр "кто на чьей стороне", больше нужно думать о том деле, которое делаем.
Команда — всегда отражение руководителя. Иногда очевидное, иногда отраженное в кривом зеркале, но всегда относительно достоверно соответствующее. Под руководителем в данном контексте я понимаю не линейного менеджера, которого поставили руководить разработчиками, а то самое "начальство", которое задаёт тон рабочих процессов, то, которое имеет непосредственное влияние на климат в коллективе, которое имеет рычаг нематериальной мотивации. Поэтому дальше я буду говорить исключительно о руководителях ПМа/лида. Работа линейного менеджера всегда во многом будет состоять из необходимости усидеть на двух стульях — работа такая. Есть компании с собственниками и менеджерами, которые подойдут одному человеку, претендующему на позицию управленца низшего звена, но для другого будут казаться неадекватами, и это тоже нормально. Вопрос в базовых установках, целях, привычных способах их достижения. Стоит ли дальше искать "свое идеальное место" — вопрос, который каждый решает для себя сам и во многом зависит от конкретной ситуации, однако тянуть в мир менеджмента программистские установки "уволюсь, а после меня хоть потоп" — как минимум не профессионально. Потому что мы живём в социуме, идеальных мест нет, а даже работа начинающего менеджера — это принципиально другая степень ответственности.
Великолепно! Я уверен, что человек, который способен "нагуглить" расклад сил среди лиц, влияющих на решение заказчика, планы инвесторов, неожиданный уход сотрудника в декрет, результаты ещё не проведённого custdev, а также прочие моменты, связанные с "недостатком данных" способен на многое.
Вот к результату требования как раз есть всегда. И даже если они выглядят "чтобы было хорошо", то это Ваша задача как менеджера выяснить "что такое хорошо, а что такое плохо". Гибкая архитектура — это прекрасно. Но дорого.
Бюджет известен только ориентировочно. Потому что, как сказано, требования меняются. Состав команды может измениться в любой момент по причинам, которые не всегда от Вас зависят. На гибкость системы всем наплевать, не за нее деньги платят. И если оторваться от разработки, то становится очевидным, что любые решения всегда приходится принимать при недостатке данных, это жизнь, и здесь как раз и нужен опыт и профессионализм. Реальность не всегда идеальна.
Только давайте не будем изображать из себя рыцарей в белых одеждах, которые смотрят наперёд, системы которых масштабируемы и гибки к изменениям, код красив, а бизнес-ценность настолько велика, что заказчики танцуют на столах джигу. Не всегда есть на это бюджет, а главное — ну нет такого количества квалифицированных сотрудников. Ведь профессиональный уровень Ваших команд все равно всегда, всегда будет ниже медианы уровня входящих в них разработчиков.
Вы, безусловно, правы, в этом и есть значительная польза от гибких методологий — разбить проект на маленькие "водопады" и добавить сверху по вкусу плюшки в виде взаимозаменяемости команд/разработчиков. Но стоит ли сразу начинать работу, принимая, что мы можем "потерять небольшой кусочек"? А если мы потеряем не один а два? А если десять? Да, требования меняются. Да, мы не знаем, что именно будем разрабатывать через два месяца. Но это никак не отменяет необходимости первоначального плана и структурированных требований к системе. Да, они изменятся. Но они должны быть.
Отвечая на Ваш первый вопрос, очевидное применение agile — работа над проектом с неуточненными требованиями, крайняя стадия этой ситуации — тестирующий гипотезы технологический стартап, однако, наиболее распространённая для России ситуация, в которой гибкие методологии являются наиболее применимыми — не продуктовая компания, описанная мной выше, а заказная, зачастую, аутсорсинговая разработка продукта с требованиями, которые могут измениться в любой момент. По второму вопросу — да, я выстраивал процессы в agile-командах.
Правы и Вы, и я, ведь любое бездумное следование тем или иным догмам приводит в подавляющем большинстве случаев только к краху, а в бизнесе важна гибкость. Однако, если взять изложенные в статье советы в комплексе, то больше они подходят чтобы сойти со страниц книг Остера для повзрослевших уже детей, чем для использования в реальном проекте. А крупицы здравых мыслей, безусловно, встречаются во многих источниках, и данная статья — не исключение, но только вот тактика без стратегии — самый быстрый путь к поражению.
Вода и ничего кроме воды, ведь фактически вся статья — о недоверии к собственным сотрудникам. Гаденькое впечатление. Удалённую работу и взаимодействие нужно уметь правильно "готовить". Большинство моих личных ошибок на первом этапе, когда я только начинал руководить географически распределенной командой, была связана как раз с попытками контролировать каждый шаг, что выливалось в демотивацию сотрудников и совершенно дурацкий микроменеджмент. Хотя до трекеров экрана я и не опускался никогда. К счастью, я сумел это достаточно быстро побороть и сделал следующие выводы на основе успешного уже опыта. Во-первых, удаленка действительно подходит не всем. Для неё нужно уметь нанимать правильных людей. Во-вторых, нужно задуматься о правильной мотивации. И я сейчас не про распевание гимнов. Человек, в первую очередь, должен получать конкурентоспособную зарплату, это необходимо, ведь тогда человек будет держаться за место, где предлагают комфортные условия труда за достойный прайс, а после этого необходимо уже объединить людей общей целью, ненавязчиво погружать их в суть происходящих процессов, для чего необходимо открытое обсуждение любых вопросов (для этого прекрасно подходят рабочие чаты, главное, не требуйте ответа в ту же секунду). Обязательные общие митинги достаточно проводить раз в неделю. В-третьих, доверяйте, наконец, сотрудникам! Контролируйте результат, а не процесс. Так пользы больше будет и для бизнеса, и для сотрудников. Вы наняли правильных людей, серьёзно. А если нет, то, в-четвёртых, направляйте слабого игрока в нужное русло, а если это не помогает, то не бойтесь расстаться с ним. Главное сделать это таким образом, чтобы остальные участники команды не воспринимали это как угрозу "следующим могу стать я". И, в-пятых, самое главное — руководитель распределенной команды должен сам быть сверхорганизован, быть вовлечен во все процессы и доступен максимальное количество времени, удалённая работа не допускает отсроченной обратной связи.
Спасибо за статью. Очевидно, что речь идёт не о "рабочих группах", формируемых краткосрочно, где главная цель — скорость, а о формировании команды для долгосрочной работы. Считаете ли Вы, что любая подобная команда должна подбираться с учётом психотипа участников? Насколько на Ваш взгляд это вообще реально с учётом имеющегося "кадрового голода"?
С большим уважением отношусь к проектам, которые в качестве одной из своих целей ставят повышение качества жизни, создание более комфортной среды или расширение возможностей людей с особыми потребностями. А есть ли у Вас программы, оптимизированные для работы со слабовидящими и незрячими учениками?
Вести спор на подобном уровне общения близком к киданию в оппонента собственными экскрементами смысла не вижу, Вы в очередной раз выставляете себя в невыгодном свете, не более. Впрочем, решать Вам. Что касается аргументации — я её привёл, это моё мнение, подкрепленное определённым опытом, не более, чем и Ваше.
Неплохая попытка воззвать к сообществу, обозначив свою принадлежность к "клубу", но нет.
Во-первых, я писал не "называете дураками", а "считать людей дураками", во-вторых все есть в Вашем тексте и комментариях.
И так далее. Но продолжим.
Тонкий укол, не правда ли? Но правда в том, что на любую проблему есть несколько точек зрения, одна и та же ситуация будет по-разному восприниматься разными людьми. Я рад, что Вы считаете мою точку зрения спорной. Это означает, что я сумел донести именно то, что хотел, именно то, что вызывает у Вас несогласие.
Ваша статья же о менеджерах проектов, разве нет? И все обсуждение было об управлении. Не передергивайте, пожалуйста.
Потому что нечего делать на менеджерских позициях, которые предполагают управление, человеку, который хочет
На этом откланиваюсь, я сказал все, что хотел.
Нет, вероятно, Вы поняли меня ошибочно. Я имею в виду, что никому не нужен специалист, неспособный организовать работу и коммуникацию внутри/с собственной командой, а претендующий лишь на администрирование уже выстроенных процессов, при этом ещё желающий чтобы его собственный авторитет был навязан "сверху".
Моё. Обязательно буду использовать там, где возможно :) Спасибо!
Спасибо за статью. Метод практически легко реализуемый и удобный, но вставлю все же свои 5 копеек: документ, а также любая таск- или crm- системы на практике удобнее для менеджеров, которые не используют в своей работе системы контроля версий. Я, все же, в том лагере, который предложит оставить привычные инструменты. Git — разработчикам, jira — управленцам. Но Ваш способ хорош.
Не буду утомлять Вас и читателей очередным длинным комментарием, поэтому отвечу кратко: первое, вся Ваша статья и есть бесконечное нытье о несправедливости мира; второе, считать людей дураками
основываясь лишь на несовпадении ценностей и мифических "недочетах" характеризует глупо только Вас; в-третьих, вот это все "профессионалу с такими работать не захочется" — нафиг таких условных "профессионалов", за которых все сделать надо в организационном плане.
gleb_l Это действительно интересный феномен психологии разработчиков: люди, которые привыкли знать что-то одно глубоко часто либо чувствуют себя экспертами во всех областях сразу (к счастью, встречается крайне редко), либо игнорируют экспертизу в тех областях знаний, от которых далеки (часто). Как Вы лично предпочитаете доносить ценность?
Прикрывать нужно тех, кто приносит пользу, которая не очевидна для вышестоящих. А остальных по ситуации — возможно, что нужно так же легко увольнять, как и прикрывать. Не стоит вести слишком много игр "кто на чьей стороне", больше нужно думать о том деле, которое делаем.
Команда — всегда отражение руководителя. Иногда очевидное, иногда отраженное в кривом зеркале, но всегда относительно достоверно соответствующее. Под руководителем в данном контексте я понимаю не линейного менеджера, которого поставили руководить разработчиками, а то самое "начальство", которое задаёт тон рабочих процессов, то, которое имеет непосредственное влияние на климат в коллективе, которое имеет рычаг нематериальной мотивации. Поэтому дальше я буду говорить исключительно о руководителях ПМа/лида. Работа линейного менеджера всегда во многом будет состоять из необходимости усидеть на двух стульях — работа такая. Есть компании с собственниками и менеджерами, которые подойдут одному человеку, претендующему на позицию управленца низшего звена, но для другого будут казаться неадекватами, и это тоже нормально. Вопрос в базовых установках, целях, привычных способах их достижения. Стоит ли дальше искать "свое идеальное место" — вопрос, который каждый решает для себя сам и во многом зависит от конкретной ситуации, однако тянуть в мир менеджмента программистские установки "уволюсь, а после меня хоть потоп" — как минимум не профессионально. Потому что мы живём в социуме, идеальных мест нет, а даже работа начинающего менеджера — это принципиально другая степень ответственности.
Я позволю себе закончить на этом неожиданную полемику.
Великолепно! Я уверен, что человек, который способен "нагуглить" расклад сил среди лиц, влияющих на решение заказчика, планы инвесторов, неожиданный уход сотрудника в декрет, результаты ещё не проведённого custdev, а также прочие моменты, связанные с "недостатком данных" способен на многое.
Вот к результату требования как раз есть всегда. И даже если они выглядят "чтобы было хорошо", то это Ваша задача как менеджера выяснить "что такое хорошо, а что такое плохо". Гибкая архитектура — это прекрасно. Но дорого.
Спасибо за статью! И хотя я в целом и не являюсь фанатиком сверхприватности, крайне некомфортно иметь дома прослушивающее устройство.
Бюджет известен только ориентировочно. Потому что, как сказано, требования меняются. Состав команды может измениться в любой момент по причинам, которые не всегда от Вас зависят. На гибкость системы всем наплевать, не за нее деньги платят. И если оторваться от разработки, то становится очевидным, что любые решения всегда приходится принимать при недостатке данных, это жизнь, и здесь как раз и нужен опыт и профессионализм. Реальность не всегда идеальна.
Только давайте не будем изображать из себя рыцарей в белых одеждах, которые смотрят наперёд, системы которых масштабируемы и гибки к изменениям, код красив, а бизнес-ценность настолько велика, что заказчики танцуют на столах джигу. Не всегда есть на это бюджет, а главное — ну нет такого количества квалифицированных сотрудников. Ведь профессиональный уровень Ваших команд все равно всегда, всегда будет ниже медианы уровня входящих в них разработчиков.
Вы, безусловно, правы, в этом и есть значительная польза от гибких методологий — разбить проект на маленькие "водопады" и добавить сверху по вкусу плюшки в виде взаимозаменяемости команд/разработчиков. Но стоит ли сразу начинать работу, принимая, что мы можем "потерять небольшой кусочек"? А если мы потеряем не один а два? А если десять? Да, требования меняются. Да, мы не знаем, что именно будем разрабатывать через два месяца. Но это никак не отменяет необходимости первоначального плана и структурированных требований к системе. Да, они изменятся. Но они должны быть.
Отвечая на Ваш первый вопрос, очевидное применение agile — работа над проектом с неуточненными требованиями, крайняя стадия этой ситуации — тестирующий гипотезы технологический стартап, однако, наиболее распространённая для России ситуация, в которой гибкие методологии являются наиболее применимыми — не продуктовая компания, описанная мной выше, а заказная, зачастую, аутсорсинговая разработка продукта с требованиями, которые могут измениться в любой момент. По второму вопросу — да, я выстраивал процессы в agile-командах.
Правы и Вы, и я, ведь любое бездумное следование тем или иным догмам приводит в подавляющем большинстве случаев только к краху, а в бизнесе важна гибкость. Однако, если взять изложенные в статье советы в комплексе, то больше они подходят чтобы сойти со страниц книг Остера для повзрослевших уже детей, чем для использования в реальном проекте. А крупицы здравых мыслей, безусловно, встречаются во многих источниках, и данная статья — не исключение, но только вот тактика без стратегии — самый быстрый путь к поражению.