Pull to refresh

Comments 49

Как-то "soft skills" звучит так, что не имеет никакого отношения к софту. Новая эйчаровская "ачивка", вместо традиционного "трудолюбив, целеустремлён, адекватен, обучаем"?

Да, под «soft skills» обычно понимают навыки общения.
Да, просто это короче. :)
https://en.wikipedia.org/wiki/Soft_skills
UFO just landed and posted this here
умение руководить джуниорами и способствовать их росту.

Зачем навыки «умение руководить джуниорами» если есть ПМ и это его работа?
Интересно, а откуда навыки управления и планирования у Senior или по принципу «обезьянка видит — обезьянка делает»? или соблюдение «корпоративых ритуалов» и «строгий Scrum» автоматически порождает хорошего управленца?
Если учесть, что, по хорошему, на управленца, на архитектора, на разрабочика нужно вложить как минимум год… другой обучения учиться — проверить навыки — поучиться еще раз — проверить навыки — готовый ПМ/Архитектор. то как-то это выглядит оптимистично слишком

"Сеньор" — по-советскороссийски будет "старший инженер-программист". Эта должность предполагает руководство менее квалифицированными кадрами. Техническое руководство прежде всего. Грубо, ПМы с джунами по техническим вопросам не общаются, первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.

Вы путаете сеньора и тимлида. Да, часто бывает так что эти должности совмещает в себе один человек, но это не одно и тоже.
Техническое руководство прежде всего.

Для технического руководства есть архитектор(ы) :)
Грубо, ПМы с джунами по техническим вопросам не общаются,
первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.

Грубо говоря все делают то, что скажет ПМ и делают так, как скажут архитекторы.
Это разные роли. Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне. Но это, противоречит, правилам управления :)

Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.

Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.

Имелось ввиду не конкретнное задание, а «тут база, тут интерфес такой, тут такая схема и стек технологий такой».
А кто будет делат и когда — «не барское дело» :)

Отправил раньше: времени предыдущий.


Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.


Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне.

Скорее о недостатке кадров говорит то, что ПМ и архитектор за каждым джуном бегают. При нормальной организации работ как раз на объёмную задачу создаётся временная группа инженеров под технический руководством старшего (вариант — ведущего) инженера, а ПМ и архитектор осуществляют лишь общий контроль и разруливают вопросы вне рамок задачи или вопросы взаимодействия между такими группами.


Это как в армии: "Иванов, Петров и Сидоров сегодня копают яму отсюда и до обеда. Иванов за старшего".

UFO just landed and posted this here
Потому что когда ПМ поручает какой-то фронт работ сеньору Васе, мидлу Диме и джунам Пете и Маше, то априори подразумевается, что отвечать за результат будет именно Вася.

Странная модель управления в виде делегирования роли управленца.
Нормальный ПМ (менеджер проекта) обычно консультируется и с Васей и с Петей перед тем как провести оценку задач и рисков, сбаласировать ресурсы, что бы критический путь попадал в ожидания Заказчика. А если не попадает то найти ресурсы или как-то решать это вопрос с клиентом.
Можно понять, что Вася скажет «технические риски не оценены (хз как делать)» или «не приняты меры для ...». перед тем как стартануть.
Можно Васю вздрючить, что не провел codereview, хреново логирование сделал, или еще какие метрики или процессы производства нарушены после того как…
Вася то тут в чем ответственный в планировании? Какие у него инструменты?
UFO just landed and posted this here
разбиение глобальной задачи на подзадачи — ПМ не может этим заниматься, поскольку не имеет достаточной технической экспертизы и не понимает что надо сделать для «добавить кнопку на сайт»

Делать должен ПМ, используя доступные ресурсы и инструменты. Senior тут такой же тулз как Excel :)

примерная оценка трудозатрат и озвучивание их ПМу — опять таки, странно считать сеньоромчеловека который не способен оценить что именно надо сделать для решения задачи

Задача " оценить сделать кнопку" это не есть планирование. Это небольшая часть :)

обучение джуниоров. Кто-то же должен их учить и объяснять почему так можно делать, а так нельзя. Опять таки, ПМ этим заниматься не способен

Это личная проблема конторы, и в частности работа ПМ что делать с рисками «не умеют и не знают» — курсы-лекции-тренинги-расстрелы- и т.д.

оценка технических рисков, да.

Не оценка рисков, а идентификация рисков. и опять же процесс управления рисками — проблема ПМ. Senior один из возможных тулзов.
UFO just landed and posted this here
Senior тут такой же тулз как Excel :)

Нет конечно. Вот на пальцах
Поставлена задача — добавить кнопку. Это именно задача сеньора сказать, что для данной кнопки надо будет менять базу, бакенд, объяснить что нельзя просто добавить колонку в таблицу, потому что у кастомеров стопицот записей в этой таблице. Как это все заменить экселем, лично мне непонятно.


В нормальной конторе, ПМ поднимет документацию, пнет ВА & архитектора и они выдадут перечень решений-изменений, потом с Senior-ом разработки проставят таски и оценки разработки, потом с QA оценят тесты. А потом ПМ будет в одиночестве раскладавать «пасьянс», что бы у ресурса не получилось 36 рабочих часов в день или не расползлась вся простынка. потом бюджеты и сроки прочее…

Я правильно вас понимаю, что где-то конторы, которые посылают своих джуниоров на лекции-курсы-тренинги и получают оттуда матерых сеньоров?

Может быть удивлю, но бывают/знаю конторы, что организовывали внутри тренинги, обучали своих сотрудников, периодически проводят последующую «переоценку» работников-активы с повышением зарплаты. Иногда оплачивают обучение и сертификацию работника с последующим повышением.

Это игра слов. В реальной жизни разница между этими понятиями весьма размыта.

Смешно :) Однажда граница этого размытия была порядка 15 миллионов долларов, другой раз ошибка порядка 3 месяцев планирования-исполнения :) Так что это конкретный порядок действий с конкретными результатами.

Вы слишком упрощенно представляете работу ПМ :)
UFO just landed and posted this here
далеко не единственное, что требуется для обучения джуниоров. И даже не основное.

Вопрос был «является ли обучение ответственностью Senior-ов ?» Оказывается есть нормальные механизмы исключающие Senior-ов из этого, по крайнй мере в рамках проекта.

Во первых вы не знаете где я работаю и какие суммы проходят через системы в разработке которых я принимал участие и сколько эти системы стоят,

Нет. не знаю. Но трактовать «оценка рисков… идентификация рисков» как «Это игра слов.» аргументируя «В реальной жизни разница между этими понятиями весьма размыта.» с учетом того, что на это есть стандарт и сертифкация, это весьма смелое утверждение.

Напомню, мой изначальный тезис был что для сеньора необходимо иметь навыки планирования, руководства и обучения.

Тогда обозначьте границы — сheck list с объективными методолгиями оценки :)
Коммуникационные навыки это вопрос психологи и они субъективны.
Самые частые ошибочные поведенческие паттерны: «интервьюировать интервьюера»

Что в этом плохого? Хочется знать, с кем потенциально предстоит работать.
Эта фраза относится к кандидатам, которые после нескольких неудачных ответов на вопросы, пытаются проверить технические знания интервьюера, что выглядит слегка наивным «ах вот ты как? а сам то сможешь ответить?».

К вопросам про работу\процессы после интервью это конечно не относится.
Кстати часто собеседуют не те люди, с которыми предстоит работать и это тоже стоит иметь ввиду.
ИМХО, на должность senior'а и выше, интервьюировать непосредственного руководителя совершенно необходимо (если это технический спец). Нужно быть уверенным в тех людях, с кем предстоит работать.
Какие вопросы вы бы задали непосредственному руководителю, чтобы быть в нем уверенным?
Из той области, которой занимаюсь: как определить тип памяти видеокарты (дискретная либо общая с CPU), не запрашивая свойств самой видекарты?

Правильный ответ: сделать отображение участка памяти из адресного пространства GPU в CPU и обратно. Если время преобразования не зависит от размера участка памяти, то физически память общая. В противном случае — либо память дискретная, либо общая, но представление объектов в памяти иное (например, тайловое вместо построчного и т. п.).
Это то, в чем должен разбираться руководитель чтобы исполнять свои обязанности?
Понятно. Это тот тип вопросов, который не стоит спрашивать на собеседовании :)

Ваш будущий руководитель совсем не обязан разбираться в каких-то определенных технических тонкостях. По разным причинам. Например он хочет нанять вас, чтобы вы смогли усилить его команду с вашими знаниями в нужных технологиях. Более подробно этот момент описан в книге «Как пасти котов» Дж. Рейнвотера.
В Российских реалиях, руководитель видится лидером во всем. И команда зачастую ждет доказательства его состоятельности. В Европе и Штатах зачастую команда удовлетворяется просто тем что им говорят «вот Боб, он ваш начальник». В России после этого идет проверка руководителя «на прочность».
У нас, пока, не все понимают что руководитель не должен быть круче всей команды, он должен исполнять другие обязанности с другими компетенциями.
Думаю, это исходит из того что начальником часто назначали самого выдающегося работника, не глядя на то, что теперь он должен выполнять совсем другие обязанности. Ну и сам по себе менеджмент в России не так давно появился, как отдельная дисциплина.
Это базовые знания в целевой области. Если их нет, то работать вместе будет трудно.

Я не представляю себе performance architect'а (моего руководителя), который не знает таких вещей. Или с такими performance architect'ами лучше не связываться. Он просто не будет понимать, чем я занят в рабочее время.
Наверное, у нас разное понятие руководителя. По-моему, архитектор это не руководитель. Но, это по-моему.
Скажем так, это человек, который ставит задачи и оценивает результаты работы. Я могу охарактеризовать такого человека, как моего непосредственного руководителя. Собственно, он и проводит техническую часть собеседования.

Если говорить о «чистых» менеджерах, которые не решают инженерные вопросы (тем не менее, являются начальством), то с ними, конечно, нет смысла говорить на исключительно технические темы. Но этот момент был отмечен в исходном комментарии.
UFO just landed and posted this here
Сколько вопросов вы зададите интервьюеру, чтобы понять насколько он технически подкован? Почему он должен отвечать на ваши вопросы, если на интервью пришли вы а не он?

Конечно технические вопросы нужно задавать и на это обычно дают время в конце интервью, но спрашивая узкие технические вопросы, вы скорее всего потратите время и не узнаете то что действительно важно. Пример с вопросом про видеокарту именно такой.

В комментарии ниже вы привели пример хорошего вопроса после интервью, а еще можно спросить – какие архитектурные проблемы сейчас есть у проекта? как их планируют решать? почему выбрали именно такой стек технологий? как устроен процесс разработки (кто ставит задачи, есть ли тестирование)?

Это тоже хорошие вопросы, которые позволяют понять и техническую развитость компании\команды, культуры разработки и проблемы над которыми нужно будет работать.

UFO just landed and posted this here
Эта фраза относится к кандидатам, которые после нескольких неудачных ответов на вопросы, пытаются проверить технические знания интервьюера, что выглядит слегка наивным «ах вот ты как? а сам то сможешь ответить?».

Может это не «злой умысел», а банальное не совпадение «глоссария» общающихся. Вполне уместная попытка собрать общий глоссарий и продолжить общение. Может несколько корявая.
А если возникает такая защитная реакция на собеседований, то явно что-то не так и возможно с обеих сторон
Вспомнив несколько таких случаев, могу сказать, что чаще всего такая защитная реакция возникает у излишне самоуверенных кандидатов, которые не очень показывают себя на интервью.

На мой взгляд такое поведение подтверждает наличие проблем с теми самыми «soft skills» у кандидата и поэтому я отнес его к «антипаттернам».
UFO just landed and posted this here
Думаю, тут имеется в виду когда собеседуемый вместо ответа на вопрос, или не отвеитв на него начинает «а ты сам знаешь frozenset, а докажи?».
Если бы дали выбор у кого проходить собеседование, то выбрала бы Данилу Штань. Самый адекватный, имхо, в рамках такого опросника.

Не знаю почему, но именно после собеседований с людьми с похожими взглядами, брали на работу. :)
Мне Данила Штань тоже показался самым адекватным из всех.
Cклоняется, да. Спасибо. :)
UFO just landed and posted this here
UFO just landed and posted this here
>> АВ: Я обращаю внимание на сочетание самостоятельности, увлечения программированием и готовности к командной работе.

Согласен на 100%.
Многие замыкаются только на языке программирования.
Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,
если новичок не умеет/не хочет работать в команде, то мало чему научиться…
А для командной профессиональной разработки требуются дополнительные компетенции и базовые навыки процесса разработки.
Можете проверить свои компетенции (и если подпишитесь на рассылку, то изучить их):
http://it-check-list.asvoip.com
Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,

А как это проверяется, если человек еще молодой и не опытный? Это при собеседовании или во время испытательного срока?

Какие-то способности и склонности будут видны даже при собеседовании, ведь человек в любом случае уже имеет какой-то опыт общения с другими людьми, совместного решения задач. В том же вузе частенько попадаются коллективные задания и т.д.
Ну и тут главное не то, что человек хорошо умеет это делать, а чтобы у него не было явного нежелания этим заниматься, что не позволит в дальнейшем нормально выстроить общение в команде.
То есть применяются субъективные критерии, и в лучшем случае «экспертная оценка» группой из нескольких коллег.
Понятно, спасибо.
Sign up to leave a comment.