Комментарии 49
Как-то "soft skills" звучит так, что не имеет никакого отношения к софту. Новая эйчаровская "ачивка", вместо традиционного "трудолюбив, целеустремлён, адекватен, обучаем"?
умение руководить джуниорами и способствовать их росту.
Зачем навыки «умение руководить джуниорами» если есть ПМ и это его работа?
Интересно, а откуда навыки управления и планирования у Senior или по принципу «обезьянка видит — обезьянка делает»? или соблюдение «корпоративых ритуалов» и «строгий Scrum» автоматически порождает хорошего управленца?
Если учесть, что, по хорошему, на управленца, на архитектора, на разрабочика нужно вложить как минимум год… другой обучения учиться — проверить навыки — поучиться еще раз — проверить навыки — готовый ПМ/Архитектор. то как-то это выглядит оптимистично слишком
"Сеньор" — по-советскороссийски будет "старший инженер-программист". Эта должность предполагает руководство менее квалифицированными кадрами. Техническое руководство прежде всего. Грубо, ПМы с джунами по техническим вопросам не общаются, первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.
Техническое руководство прежде всего.
Для технического руководства есть архитектор(ы) :)
Грубо, ПМы с джунами по техническим вопросам не общаются,
первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.
Грубо говоря все делают то, что скажет ПМ и делают так, как скажут архитекторы.
Это разные роли. Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне. Но это, противоречит, правилам управления :)
Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.
Отправил раньше: времени предыдущий.
Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.
Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне.
Скорее о недостатке кадров говорит то, что ПМ и архитектор за каждым джуном бегают. При нормальной организации работ как раз на объёмную задачу создаётся временная группа инженеров под технический руководством старшего (вариант — ведущего) инженера, а ПМ и архитектор осуществляют лишь общий контроль и разруливают вопросы вне рамок задачи или вопросы взаимодействия между такими группами.
Это как в армии: "Иванов, Петров и Сидоров сегодня копают яму отсюда и до обеда. Иванов за старшего".
Потому что когда ПМ поручает какой-то фронт работ сеньору Васе, мидлу Диме и джунам Пете и Маше, то априори подразумевается, что отвечать за результат будет именно Вася.
Странная модель управления в виде делегирования роли управленца.
Нормальный ПМ (менеджер проекта) обычно консультируется и с Васей и с Петей перед тем как провести оценку задач и рисков, сбаласировать ресурсы, что бы критический путь попадал в ожидания Заказчика. А если не попадает то найти ресурсы или как-то решать это вопрос с клиентом.
Можно понять, что Вася скажет «технические риски не оценены (хз как делать)» или «не приняты меры для ...». перед тем как стартануть.
Можно Васю вздрючить, что не провел codereview, хреново логирование сделал, или еще какие метрики или процессы производства нарушены после того как…
Вася то тут в чем ответственный в планировании? Какие у него инструменты?
разбиение глобальной задачи на подзадачи — ПМ не может этим заниматься, поскольку не имеет достаточной технической экспертизы и не понимает что надо сделать для «добавить кнопку на сайт»
Делать должен ПМ, используя доступные ресурсы и инструменты. Senior тут такой же тулз как Excel :)
примерная оценка трудозатрат и озвучивание их ПМу — опять таки, странно считать сеньоромчеловека который не способен оценить что именно надо сделать для решения задачи
Задача " оценить сделать кнопку" это не есть планирование. Это небольшая часть :)
обучение джуниоров. Кто-то же должен их учить и объяснять почему так можно делать, а так нельзя. Опять таки, ПМ этим заниматься не способен
Это личная проблема конторы, и в частности работа ПМ что делать с рисками «не умеют и не знают» — курсы-лекции-тренинги-расстрелы- и т.д.
оценка технических рисков, да.
Не оценка рисков, а идентификация рисков. и опять же процесс управления рисками — проблема ПМ. Senior один из возможных тулзов.
Senior тут такой же тулз как Excel :)
Нет конечно. Вот на пальцах
Поставлена задача — добавить кнопку. Это именно задача сеньора сказать, что для данной кнопки надо будет менять базу, бакенд, объяснить что нельзя просто добавить колонку в таблицу, потому что у кастомеров стопицот записей в этой таблице. Как это все заменить экселем, лично мне непонятно.
В нормальной конторе, ПМ поднимет документацию, пнет ВА & архитектора и они выдадут перечень решений-изменений, потом с Senior-ом разработки проставят таски и оценки разработки, потом с QA оценят тесты. А потом ПМ будет в одиночестве раскладавать «пасьянс», что бы у ресурса не получилось 36 рабочих часов в день или не расползлась вся простынка. потом бюджеты и сроки прочее…
Я правильно вас понимаю, что где-то конторы, которые посылают своих джуниоров на лекции-курсы-тренинги и получают оттуда матерых сеньоров?
Может быть удивлю, но бывают/знаю конторы, что организовывали внутри тренинги, обучали своих сотрудников, периодически проводят последующую «переоценку» работников-активы с повышением зарплаты. Иногда оплачивают обучение и сертификацию работника с последующим повышением.
Это игра слов. В реальной жизни разница между этими понятиями весьма размыта.
Смешно :) Однажда граница этого размытия была порядка 15 миллионов долларов, другой раз ошибка порядка 3 месяцев планирования-исполнения :) Так что это конкретный порядок действий с конкретными результатами.
Вы слишком упрощенно представляете работу ПМ :)
далеко не единственное, что требуется для обучения джуниоров. И даже не основное.
Вопрос был «является ли обучение ответственностью Senior-ов ?» Оказывается есть нормальные механизмы исключающие Senior-ов из этого, по крайнй мере в рамках проекта.
Во первых вы не знаете где я работаю и какие суммы проходят через системы в разработке которых я принимал участие и сколько эти системы стоят,
Нет. не знаю. Но трактовать «оценка рисков… идентификация рисков» как «Это игра слов.» аргументируя «В реальной жизни разница между этими понятиями весьма размыта.» с учетом того, что на это есть стандарт и сертифкация, это весьма смелое утверждение.
Напомню, мой изначальный тезис был что для сеньора необходимо иметь навыки планирования, руководства и обучения.
Тогда обозначьте границы — сheck list с объективными методолгиями оценки :)
Коммуникационные навыки это вопрос психологи и они субъективны.
Самые частые ошибочные поведенческие паттерны: «интервьюировать интервьюера»
Что в этом плохого? Хочется знать, с кем потенциально предстоит работать.
К вопросам про работу\процессы после интервью это конечно не относится.
Кстати часто собеседуют не те люди, с которыми предстоит работать и это тоже стоит иметь ввиду.
Правильный ответ: сделать отображение участка памяти из адресного пространства GPU в CPU и обратно. Если время преобразования не зависит от размера участка памяти, то физически память общая. В противном случае — либо память дискретная, либо общая, но представление объектов в памяти иное (например, тайловое вместо построчного и т. п.).
Ваш будущий руководитель совсем не обязан разбираться в каких-то определенных технических тонкостях. По разным причинам. Например он хочет нанять вас, чтобы вы смогли усилить его команду с вашими знаниями в нужных технологиях. Более подробно этот момент описан в книге «Как пасти котов» Дж. Рейнвотера.
У нас, пока, не все понимают что руководитель не должен быть круче всей команды, он должен исполнять другие обязанности с другими компетенциями.
Думаю, это исходит из того что начальником часто назначали самого выдающегося работника, не глядя на то, что теперь он должен выполнять совсем другие обязанности. Ну и сам по себе менеджмент в России не так давно появился, как отдельная дисциплина.
Я не представляю себе performance architect'а (моего руководителя), который не знает таких вещей. Или с такими performance architect'ами лучше не связываться. Он просто не будет понимать, чем я занят в рабочее время.
Если говорить о «чистых» менеджерах, которые не решают инженерные вопросы (тем не менее, являются начальством), то с ними, конечно, нет смысла говорить на исключительно технические темы. Но этот момент был отмечен в исходном комментарии.
Конечно технические вопросы нужно задавать и на это обычно дают время в конце интервью, но спрашивая узкие технические вопросы, вы скорее всего потратите время и не узнаете то что действительно важно. Пример с вопросом про видеокарту именно такой.
В комментарии ниже вы привели пример хорошего вопроса после интервью, а еще можно спросить – какие архитектурные проблемы сейчас есть у проекта? как их планируют решать? почему выбрали именно такой стек технологий? как устроен процесс разработки (кто ставит задачи, есть ли тестирование)?
Это тоже хорошие вопросы, которые позволяют понять и техническую развитость компании\команды, культуры разработки и проблемы над которыми нужно будет работать.
Эта фраза относится к кандидатам, которые после нескольких неудачных ответов на вопросы, пытаются проверить технические знания интервьюера, что выглядит слегка наивным «ах вот ты как? а сам то сможешь ответить?».
Может это не «злой умысел», а банальное не совпадение «глоссария» общающихся. Вполне уместная попытка собрать общий глоссарий и продолжить общение. Может несколько корявая.
А если возникает такая защитная реакция на собеседований, то явно что-то не так и возможно с обеих сторон
На мой взгляд такое поведение подтверждает наличие проблем с теми самыми «soft skills» у кандидата и поэтому я отнес его к «антипаттернам».
Не знаю почему, но именно после собеседований с людьми с похожими взглядами, брали на работу. :)
Согласен на 100%.
Многие замыкаются только на языке программирования.
Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,
если новичок не умеет/не хочет работать в команде, то мало чему научиться…
А для командной профессиональной разработки требуются дополнительные компетенции и базовые навыки процесса разработки.
Можете проверить свои компетенции (и если подпишитесь на рассылку, то изучить их):
http://it-check-list.asvoip.com
Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,
А как это проверяется, если человек еще молодой и не опытный? Это при собеседовании или во время испытательного срока?
Ну и тут главное не то, что человек хорошо умеет это делать, а чтобы у него не было явного нежелания этим заниматься, что не позволит в дальнейшем нормально выстроить общение в команде.
Как пройти собеседование в компанию мечты? Советы от тимлидов IT-компаний