Pull to refresh
1
0
Logros.tech @Logros_tech

Сервис бизнес-оценки и развития команд

Send message
Здесь я оно видно, как смешивается понятие «Senior» и «тимлид», отсюда довольно много проблем. Кажется, Senior должны мочь сначала стать нормальными Senior и понимать бизнес-требования, чтобы потом, может быть, стать тимлидами. А может архитекторами.
У нас отсроенная система Управления проектами. Мы начали проекты тоже отдавать все больше вниз, и несколько неруководящих сотрудников стали РП. Мы были удивлены, что эта стезя им была вполне даже интересна (а мы ожидали зубовный скрежет на требования Проектного офиса). Правда, сейчас им куда больше интересны продуктовые команды. Ну что ж, пусть дерзают.
Да даже не скажут, что софт-скиллов не хватает, в большинстве случаев так и не узнаете, по каким причинам, кроме недочетов в хард-скиллз ы не прошли. В этом и проблема, потому что в картине мира разработчика того о чем ему НЕ сказали так и не появилось. А значит нечего развивать и корректировать. Замкнутый на хард-скиллз круг.
А что с управлением бенчом — ад? У меня нет особого опыта, есть только галлюцинации, что на бенчах сидят только средненькие миддлы и джуны (которых вообще трудно пристроить), и сложность только в том, чтобы с бенча их в проект какой угодно сбыть… Не так?
Более того — одна функция, но обилие навыков: организация своей работы и ближнего, коммуникация и аргументация, дробление задач больше-мельче/сложнее-проще, зачатки планирования и контроль, где-то и мотивация с поддержкой… Плацдарм для менеджмента, по сути
В нашем же случае речь идет скорее о работе стейкхолдера. Тест расположен на стороннем сервисе, на который работу которого мы не влияем. Можем жаловаться, но масс-маркет подход стейкхолдера избавляет нас от шансов на успех. Знаю, что и в компаниях происходят такие случаи (когда на аутсорсе целые компании и они косячат). Как (кроме категорической замены стейкхолдера) регулируются такие случаи?
Я знаю несколько непоследних компаний, в которых разработчики обязательно ходят на переговоры пре-сэйловские и выступают перед заказчиками на ПСИ (приемо-сдаточные испытания), даже презентации могут сами готовить. Не все, конечно, шибко рады, но, как говаривали выше, границы стираются. Плюс много небольших проектов, где разработки сами себе Руководители проектов и спецы, никто им не выделит отдельного супер-спикера.
Да? Здорово, что есть такие кейсы! Я за то, чтобы где возможно, не замешивать часто противоречащие друг другу верхенуровневые хард и софт-скиллы.
Кажется, мы говорим о разных вещах. Вы — о конкретных требованиях к конкретной позиции с конкретной спецификой и должностями обязанностями, а мы — в целом об оценке уровня программиста. Оценка для конкретной позиции с требованиями для конкретной компании — одно, а в целом чем оперирует специалист и в какой степени, а чем нет — это другое. Скорее мы видим общую картину и дальше уже имеем дело с требованиями. Определяемся — для какой позиции и 0% ничего страшного, а для чего и 70% — мало. Если нам нужен Middle — набор процентов по одним блокам, Senior — другой по другим.
А границы далеко не всех радуют. Многие в них видят потолки) Не припомню, чтобы у меня лично или у кого-то из коллег возникали вопросы с полномочиями, когда они приходили с видением проблемы, аргументами, приносили решение и демонстрировали готовность действовать
Да, это более комплексная картина)
Мы за партнерские отношения. Обе стороны смотрят и оценивают, обе стороны выбирают.
… и даже не о тимлиде: речь об оценке программистов всех уровней, чуть прицельнее — Senior. У тимлидов уже много совсем других критериев — более сложных hard и soft.
Здесь мы говорим не о Гендиректоре (он уже давно «в менеджмент»), а все-таки, скорее о Ведущих спецах-химиках фирмы. Ну и опять же — спрашивать-то можно. Вопрос только спрашивать ли только это или еще много чего и как интерпретировать. Мы отражаем как это интерпретируют компании. А сами мы смотрим — если по языковому блоку так-сяк, а по самым крутым и сложным здорово… Нам эта картина интересна (писали уже об этом выше). На собеседовании поговорим и уточним.
Мы против крайностей. И согласны с предыдущим оратором. Я знаю много компаний, в который «в твоей власти» много зон, где ты способен предлагать хорошие идеи, реально что-то сделать помочь и нести ценность. Насколько широк или узок этот круг и насколько жесткие у него границы — каждый зачастую решает сам.
Уровни начинают развиваться — точно. Но не степень личностной ответственности каждого. Один из краеугольных камней бирюзовых организаций именно в том, что члены команды разделяют высокую степень ответственности. Именно поэтому структура способна быть плоской, а руководителя в официальном эквиваленте вообще уже может не быть. Бирюза — она для высокооответственных и прокачано софт-скилловых, иначе все развалится)
Один из знакомых руководителей тоже говорил, что разницы визуальной никакой. Что джуны пилят практически те же задачи, что и синьоры, просто за ними нужно приглядывать. И что джуны хорошие вообще должны уметь все. Но это была небольшая компания и небольшой отдел разработки, с неЯндексовским все-таки уровнем задач
Ну что сказать, ничего не выдумываем — в компаниях это must. Логика такая: даже оперной диве не должно быть чуждо сальфеджио, гонщик способен прокатиться на жигулях ну и т.д. Однако, если спрашивают только ООП и паттерны, уточните все же, Senior ли нужен. Корректно уточнять требования и объяснять свою позицию же никто не запрещает.
Уровень Senior — это плацдарм для целого веера позиций: тимлид, техлид, архитектор, скраммастер, менеджер по продукту (сейчас все больше любят их с техническим бэкграундом если это ИТ-продукт), и даже видим все больше вакансий аналитиков с программистским бэкграундом… Это всего на одну ступеньку дальше. Однако, на этих позициях ждут, прежде всего, Senior-ов. Мало кто пригласит в техлиды, тимлиды и т.д. специалиста среднего уровня (не знаю таких случаев).
Это как раз то, почему мы все же не рекомендуем на высоком уровне «забывать» про базовые хард-скиллы. Потому что, по-факту, в компаниях все равно на них смотрят, какого бы уровня вакансия не была. Меряют так серьезность отношения разработчика к своей подготовке. И часто никакой балансировки по степени сложности заданий, что усугубляет картину.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity