Для организаций занимающихся заказной разработкой я бы посоветовал в первую очередь обратить внимание на существование дисциплины «управление продуктом» и роли «менеджера продукта».
Они упомянуты в статье, но хочется подчеркнуть, что именно самотечный подход к управлению продуктом чаще всего подводит владельцев. Даже крутых разработчиков. Возможно их даже больше, так как они уверены, что их крутость определит успех продукта.
Это вы про PMBOK, его я сам упомянул в своем комментарии, я же спрашивал про PMBOOK. Возможно это только опечатка, но может немного характеризует глубину знаний автора.
Чрезмерно категорично, интернет-маркетолог — плохой, проджект-менеджер — хороший.
Причем при чтении я прямо-таки ощущал каких-то конкретных личностей которые стоят за этими словами.
Почти наугад из таблицы сравнения:
«Раздутое эго, профессиональный сленг, неумение выстроить качественное взаимодействие — с отделами продаж и другими» — ну я и менеджеров проектов таких немало знаю.
«Эффективен всегда» — да ладно, просто потому, что я назовусь руководителем проекта и PMBOK заботаню я стану навсегда эффективным?
«Неэффективен. Использует эффективно лишь те, где разбирается. Где не разбирается — либо отказывается, либо портит отношения с подрядчиками, либо выбирает неэффективных» — тут вы какого-то вредину описываете, не обязательно все маркетологи такие?
Ну и вся статья на таких спорных утверждениях построена.
Возможно если написать статью в ключе: «Зачем интернет-маркетологу уметь управлять проектами? » то вышел бы толк. Руководство проектами — это и должность, но это и умение, очень многим нужно это умение иметь и развивать в своей деятельности.
Пример рекламной статьи, которая при этом полезна, спасибо!
Однако утверждение в заголовке преувеличено: «онлайн-инструменты лучше,
чем суровый админ», сурового админа эти инструменты не заменят, но наверняка помогут ему.
Если задавать «кем вы видите себя через 5 лет» в наши дни, то это будет выглядеть как провокация, иногда именно это цель, например если есть подозрение, что кандидат может вести себя неадекватно и нужно это проверить.
Именно про будущие планы разработчикам вопросы редко задают, в целом они предсказуемы в своих намерениях.
Однако в некоторых случаях важно понять, коррелирует ли личный план кандидата с планами компании на кандидата (собеседование — это же процесс переговоров о сотрудничестве).
Например кандидат часто меняет сферу деятельности, или много времени посвятил изучению другой специальности, или демонстрирует какие-то специфичные навыки.
Для разработчика вообще хороший ответ — «наверняка буду разработчиком», джуниору вообще смело можно говорить, что понятия не имеет. Правильных ответов нет, есть неправильные — например агрессия в любом проявлении, так как в хороших компаниях лучше рискнут потерять квалифицированного кандидата, чем внести разлад в команду пригласив неадеквата.
Правильного ответа на «зачем сюда пришли» также нет, есть неправильные. Если хотите продемонстрировать потенциальную лояльность — найдите факторы привлекающие вас, хотите показать независимость — скажите, что рассматриваете компанию наряду со многими другими.
Опытный собеседователь будет наблюдать как соотносятся ваши рассуждения со всеми другими фактами и составит о вас какую-то в карину в целом (если, к примеру, показания не будут сходиться, то это может быть свидетельством вашей непоследовательности, или того хуже — намеренного введения в заблуждение), и эта картина будет иметь значение, а не ответы на отдельные вопросы и средний балл по ним в результате.
В своей практике я стараюсь задавать гораздо более провакационные вопросы специалистам, чья деятельность связана с общением с внешним миром — поддержка, аналитики, руководящий состав особенно, чтобы увидеть, как они будут представлять компанию. Конечно, подвергать разработчиков или тестировщиков стрессу чаще всего излишне, но всякие обстоятельства бывают, наперед не знаешь какие именно вопросы задать, все зависит от кандидата и контекста.
Видимо и впрямь накипело, я не понял суть вашего возмущения.
Я лишь заявил, что практически для любого вопроса может быть место на собеседовании.
По вопросам ведущего собеседование можно понять, что он пытается выяснить, какие слабые места он видит в вас и насколько вообще понимает, что делает.
То чувство камня в свой огород, так как сталкивались с автором на собеседовании.
Как раз крупная компания работа на Энтерпрайз, большой поток кандидатов, подобные викторинные вопросы также присутствовали.
Статья понравилась, обращает внимание на проблему, без фанатичного склонения к какому-то другому методу.
Добавлю пару комментариев с другой стороны баррикад:
Практически любые вопросы могут иметь смысл, если уметь правильно понимать ответы на них, под правильно подразумеваю учитывать контекст в котором возникла потребность в найме. Бывает полезны вопросы и «кем вы видите себя через 5 лет» и «зачем вы пришли к нам на собеседование» и как написать сортировку. К сожалению многие задают их, но не умеют интерпретировать ответы.
В аутсорсинговых организациях программисты часто подвергаются собеседованию со стороны заказчика, где задаются те же самые викторинные вопросы и нужно понимать, как покажет себя на таком собеседовании потенциальный работник.
Бывает, что сам не согласен со многим происходящим в компании, но профессионализм требует либо разделять подходы компании, либо менять, либо уходить. Менять что-либо чаще всего бывает сложно просто из-за политических противостояний.
P.S. Удивился, что не нашел упоминания про тест стаканом воды, мне он понравился, хоть я и не понял сразу, что это был тест.
Спасибо, рад, конечно, что статья еще помогает, но с тех пор закрепились Ansible, Docker, Амазон предлагает вообще забыть о том как запускать веб-приложения.
Статья перешла в раздел «интересно сделать самому», в реальных приложениях сегодня делают по-другому.
Сайта нет, у нас мобильное приложение.
В боевом режиме коннектор успешно работает на ограниченном круге пользователей, но продукт в продакшн не вышел, не могу поделиться большей информацией.
Ждал понедельника, чтобы уточнить информацию.
1. Нам поступило требование поддержать именно OAuth 2.0 / OpenID Connect.
2. В заявлении на подключение к ЕСИА для негосударственных учреждений не было возможности выбрать SAML. Как дело обстоит сейчас не знаю.
Вполне вероятно, что ваша идея заработает, не могу ни подтвердить, ни опровергнуть.
Спасибо за ваше мнение!
Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
Было бы очень интересно услышать мнения непосредственных участников. Возможно это случай удачного разделения обязанностей тимлида между несколькими членами команды.
«Совершенствование процесса в команде» — что вы имеете в виду?
Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
Можно вообразить частный случай для иллюстрации:
Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.
Это и есть одна из задач тимлида, как тимлида, другая деятельность, такая как проектирование, уточнение требований и прочее сотрудник осуществляет от лица других ролей.
Спасибо, всегда можно сделать лучше, было бы время.
Мои изучения Scrum'а и допытывания всяких гуру привели меня к выводу, что для Scrum'а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
Обратная связь очень важна в работе тимлида, я отношу ее к инструментам поддержания и развития компетенции, а в некоторых случаях и поддержания настроений в команде.
Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.
Спасибо за отзыв! Я предложил метод, а использовать или нет — ваше дело.
Для организаций занимающихся заказной разработкой я бы посоветовал в первую очередь обратить внимание на существование дисциплины «управление продуктом» и роли «менеджера продукта».
Они упомянуты в статье, но хочется подчеркнуть, что именно самотечный подход к управлению продуктом чаще всего подводит владельцев. Даже крутых разработчиков. Возможно их даже больше, так как они уверены, что их крутость определит успех продукта.
Причем при чтении я прямо-таки ощущал каких-то конкретных личностей которые стоят за этими словами.
Почти наугад из таблицы сравнения:
«Раздутое эго, профессиональный сленг, неумение выстроить качественное взаимодействие — с отделами продаж и другими» — ну я и менеджеров проектов таких немало знаю.
«Эффективен всегда» — да ладно, просто потому, что я назовусь руководителем проекта и PMBOK заботаню я стану навсегда эффективным?
«Неэффективен. Использует эффективно лишь те, где разбирается. Где не разбирается — либо отказывается, либо портит отношения с подрядчиками, либо выбирает неэффективных» — тут вы какого-то вредину описываете, не обязательно все маркетологи такие?
Ну и вся статья на таких спорных утверждениях построена.
Возможно если написать статью в ключе: «Зачем интернет-маркетологу уметь управлять проектами? » то вышел бы толк. Руководство проектами — это и должность, но это и умение, очень многим нужно это умение иметь и развивать в своей деятельности.
P. S. А что такое PMBOOK?
IT-инфраструктуры:
онлайн-инструменты лучше,
чем суровый админ
Однако утверждение в заголовке преувеличено: «онлайн-инструменты лучше,
чем суровый админ», сурового админа эти инструменты не заменят, но наверняка помогут ему.
Именно про будущие планы разработчикам вопросы редко задают, в целом они предсказуемы в своих намерениях.
Однако в некоторых случаях важно понять, коррелирует ли личный план кандидата с планами компании на кандидата (собеседование — это же процесс переговоров о сотрудничестве).
Например кандидат часто меняет сферу деятельности, или много времени посвятил изучению другой специальности, или демонстрирует какие-то специфичные навыки.
Для разработчика вообще хороший ответ — «наверняка буду разработчиком», джуниору вообще смело можно говорить, что понятия не имеет. Правильных ответов нет, есть неправильные — например агрессия в любом проявлении, так как в хороших компаниях лучше рискнут потерять квалифицированного кандидата, чем внести разлад в команду пригласив неадеквата.
Правильного ответа на «зачем сюда пришли» также нет, есть неправильные. Если хотите продемонстрировать потенциальную лояльность — найдите факторы привлекающие вас, хотите показать независимость — скажите, что рассматриваете компанию наряду со многими другими.
Опытный собеседователь будет наблюдать как соотносятся ваши рассуждения со всеми другими фактами и составит о вас какую-то в карину в целом (если, к примеру, показания не будут сходиться, то это может быть свидетельством вашей непоследовательности, или того хуже — намеренного введения в заблуждение), и эта картина будет иметь значение, а не ответы на отдельные вопросы и средний балл по ним в результате.
В своей практике я стараюсь задавать гораздо более провакационные вопросы специалистам, чья деятельность связана с общением с внешним миром — поддержка, аналитики, руководящий состав особенно, чтобы увидеть, как они будут представлять компанию. Конечно, подвергать разработчиков или тестировщиков стрессу чаще всего излишне, но всякие обстоятельства бывают, наперед не знаешь какие именно вопросы задать, все зависит от кандидата и контекста.
Я лишь заявил, что практически для любого вопроса может быть место на собеседовании.
По вопросам ведущего собеседование можно понять, что он пытается выяснить, какие слабые места он видит в вас и насколько вообще понимает, что делает.
«это попросить стакан воды на собеседовании» — тот самый.
Как раз крупная компания работа на Энтерпрайз, большой поток кандидатов, подобные викторинные вопросы также присутствовали.
Статья понравилась, обращает внимание на проблему, без фанатичного склонения к какому-то другому методу.
Добавлю пару комментариев с другой стороны баррикад:
P.S. Удивился, что не нашел упоминания про тест стаканом воды, мне он понравился, хоть я и не понял сразу, что это был тест.
Статья перешла в раздел «интересно сделать самому», в реальных приложениях сегодня делают по-другому.
В боевом режиме коннектор успешно работает на ограниченном круге пользователей, но продукт в продакшн не вышел, не могу поделиться большей информацией.
1. Нам поступило требование поддержать именно OAuth 2.0 / OpenID Connect.
2. В заявлении на подключение к ЕСИА для негосударственных учреждений не было возможности выбрать SAML. Как дело обстоит сейчас не знаю.
Вполне вероятно, что ваша идея заработает, не могу ни подтвердить, ни опровергнуть.
Видимо мы живем в разных мирах, так как в моем я не слышал о специльно выделенной должности — people manager, которая подразумевает принятие на себя обязанностей тимлида. Как он существует, в команде или вне ее? Было бы интересно, если бы вы привели ссылку на вакансию или перечень требований в любой из компаний.
Возможно вы подразумеваете тех сотрудников, что существуют для решения задач найма и поддержания командного духа и т.п.? Или линейное руководство, в чьи задачи как раз и входит формирование команд, способных решать задачи проектов? Это — не тимлиды и своим наличием они не отменяют необходимости существования тимлидов в рамках непосредствнно команд разработки.
Тимлид отвечает за то, чтобы команда справлялась со взятыми на себя обязательствами.
Чем эффективнее справляется, тем эффективнее деятельность самого тимлида.
Можно вообразить частный случай для иллюстрации:
Работа в паре с давним товарищем, днем вместе работают, ходят на дни рождения подруг/детей.
Один из них тимлид, причем это тимлидство практически не проявляется в работе — все обязанности давно явно или неявно распределены, взаимное доверие развито, оба знают в каких вопросах кто сильнее, лишь в некоторых случаях возникают споры, но оба заранее уже знают, чье мнение будет окончательным. Такое взаимодействие внутри команды — то к чему стремятся (должны по крайней мере) любые тимбилдеры, тут уже нечего совершенствовать. Можно подтягивать технические компетенции, не дать застрять в прошлом технологическом веке, но внутренние процессы команды отлажены до практического предела.
Когда людей в команде больше, знают они друг друга хуже, уровень компетенции разный, ответственность различается, возраст расходится, тогда задача тимлида усложняется, и наладить взаимодействие в приемлемый для проекта срок — задача тимлида, за которую он взялся исходя из каких-то своих соображений, когда принимал людей в команду.
Это и есть одна из задач тимлида, как тимлида, другая деятельность, такая как проектирование, уточнение требований и прочее сотрудник осуществляет от лица других ролей.
Мои изучения Scrum'а и допытывания всяких гуру привели меня к выводу, что для Scrum'а наличие или отсутствие явно обозначенного тимлида — лишь детали реализации, Scrum говорит, что соберите людей вместе, дайте им задачи, не лезьте в их дела, они сами разберутся, а лидер появится сам собой. Но лично я считаю, что подтолкнуть команду к тому, чтобы лидером стал наиболее подходящий для этого кандидат и меньше времени тратилось на борьбу за лидерство (все равно она будет, даже если никто в этом не признается).
Давать отрицательную оценку действительно очень сложно, из общих советов: делать это только наедине, кроме случаев когда точно понимаешь, что в данный момент нужно сделать это публично.