Ответы пользователя по тегу Карьера в IT
  • Что должен уметь менеджер проекта (продукта)?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Не обижайтесь, но, судя по задаваемым вопросам, Вам еще вообще рано думать о таких позициях. Трудоустройство - это, как бы, одно (тут может и повезти), но вот успешная работа - совсем другое. А для этого Вам нужно еще набираться и набираться опыта. По вопросам:

    1. Менеджер проекта организует разработку так, чтоб с доступными ресурсами уложиться в бюджет (денежный или временной) и дать на выходе работающий и качественный продукт. Для этого он в первую очередь руководит людьми, координирует сроки, внешние зависимости, определяет методики, устанавливает формы отчетности, но может и персонал набирать, и технику закупать... короче, он отвечает за все, что нужно для того, чтоб все крутилось, т.е. определяет КАК разрабатывать.

    Менеджер продукта отвечает за то, чтоб не просто что-то там разрабатывалось, но еще это что-то и продать, и, самое главное, получить прибыль. Его задачи - сделать продукт конкурентоспособным, востребованным на рынке, но сделать это максимально эффективно и в нужные сроки. Для этого он общается с потребителем (изучает его потребности), с конкурентами (изучает их сильные и слабые места), следит за трендами на рынке и в технологиях, за ценами, за патентами и торговыми марками, за стандартами и регулирующим законодательством, тусует на выставках, находит партнеров, составляет и заключает с ними договора... короче, он полностью определяет стратегию продукта, т.е. ЧТО нужно разрабатывать.

    Разумеется, оба работают в тесном контакте друг с другом и, как правило, без формального "разграничения должностных обязанностей", знают продукт не хуже (а иногда и лучше) любого рядового разработчика и, в конечном итоге, совместно определяют успех или провал всей затеи... за что и получают либо лавры победителей и премии, либо пинка под зад. Иногда, в небольших проектах все это может выполнять один человек.

    2. Для трудоустройства - как повезет, а вот для работы нужно обладать солидными знаниями и опытом во всех этих областях плюс, в идеале, глубокими знаниями технической стороны вопроса... как минимум, знать, чем отличается интерфейс от абстрактного класса ;)

    3. Если это важно для продукта, то ОЧЕНЬ пригодятся, а если нет, то придется разбираться с теми технологиями, которые важны.

    4. Корочка сама по себе мало кого интересует, но хотя бы общие представления о методиках управления проектами, формах отчетности, документообороте, психологии, стандартах, законодательстве и аналогичных вещах скорее всего ожидаются. Без нее (особенно если нет портфолио) велика вероятность, что у соискателя даже не было шанса узнать о существовании этих замечательных вещей, так что такие резюме часто отметают уже кадровики, и до собеседования просто дело не доходит.

    5. Самая смешная часть вопроса... сначала покажите на деле, что способны заработать денег для фирмы, а потом уже задумывайтесь над тем, сколько просить за этот свой навык :)
    Ответ написан
    4 комментария
  • Как из Team Lead вырасти до CTO?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Прежде всего, нужно определиться с терминологией. СТО, это, собственно, не столько должность, сколько роль в организации, и ее интерпретация, к сожалению, бывает очень разной. Грубо говоря, от "это чувак, ответственный за снижение стоимости IT и прогулы программистов/админов", т.е. эдакий староста группы придурковатых гиков в свитерах и джинсах, и до "это чувак, от стратегических решений которого зависит наше будущее", т.е. ключевая фигура, на уровне СЕО или безопасника :) Соответственно, от кандидата могут ожидаться совершенно разные качества.

    Первое обычно имеет место быть в организациях, для которых IT/разработка - второстепенная составляющая бизнеса, от которой, по сути, мало что зависит. От "СТО" ожидаются в первую очередь такие скиллы, как умение находить дешевую рабсилу, умение закупать дешевую технику и умение вести отчетность, а понимание разницы между абстрактным классом и интерфейсом или, упаси господи, знание современных методик и технологий не только излишне, но даже прямо вредно для карьеры, т.к. это все дорого и никому не нужно :) Соответственно, определяющими факторами трудоустройства являются количество подчиненных на предыдущих должностях помноженное на количество уровней менеджмента в организации, помноженное на длину ног секретарши непосредственного начальника. Для таких должностей желательно избавиться от всяческих принципов, натренировать печень и раз и навсегда усвоить рекурсивность правила: успехи - заслуга начальника, провалы - следствие косяков подчиненных.

    Второе характерно для бизнеса, непосредственно зависящего от IT/разработки. Тут все и сложнее, и, одновременно, проще. Сложнее, т.к. нужен опыт, обширные знания как предмета, так и в области менеджмента, умение работать с людьми (не только с подчиненными), знание рынка, конкуренции и т.д. и т.п. А проще, т.к. в конечном счете, решающим является вопрос: "а покажи ка дружище, что ты уже сделал для других". Какие проблемы и как ты решил? Какие продукты были созданы под твоим руководством, и насколько они были успешны? Какие технологии ты внедрил, и что это принесло? Что ты изменил/улучшил в процессах? Короче, от кандидата ожидаются не какие-то конкретные скиллы или сертификаты, а банальное умение "делать так, чтоб все работало", убедительно проиллюстрированное соотв. портфолио. Нормальный СТО должен одинаково уметь и найти баг в коде, и утрясти с партнерами технические детали контракта, и подменить заболевшего скраммастера, и в воскресенье ночью накормить команду пицей/кофе, после чего в понедельник утром таки сдать заказчику законченный проект и повести всех на пиво. И все это - не для того, чтоб стать незаменимым, а чтоб создать коллектив единомышленников, который, если понадобится, точно так же вовремя сдаст горящий проект и без него.

    Нарисованная картинка, конечно, немножко черно-белая, и в живой природе встречаются самые причудливые комбинации понимания роли СТО в компании (я сам побывал в разных шкурах). Если попытаться вывести некую универсальную закономерность, то она в том, что чем реальность ближе к первому варианту, тем больше вероятность того, что контора окажется в заднице и все равно придется искать новую работу, а чем она ближе ко второму - тем больше у фирмы шансов на успех/развитие (а у ее СТО, соответственно - новых проблем, которые предстоит решать).

    Так что могу посоветовать начинать не с резюме, а с определения собственного представления о должности СТО, на которую лично Вы хотели бы попасть, а потом просто поискать работодателя с таким же пониманием. Тогда вопросы, что конкретно написать в резюме, сказать на собеседовании или какие скиллы подтянуть, прояснятся сами собой.
    Ответ написан
    Комментировать
  • Может ли человек уметь профессионально работать с более чем одним языком?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Все еще хуже... тот, кто не знает хотя бы два-три языка - вообще не может считаться профессионалом :)
    Ответ написан
    Комментировать
  • Как отсеять слабых кандидатов на собеседование?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    На этапе отбора нужно внимательно смотреть "послужной список". Наблюдение: если в списке помимо названия работодателей только общее "наведение тени на плетень", кандидат отпадет после трех-пяти вопросов по делу. Если в списке указаны стеки технологий и конкретная роль в проекте (сделал то-то, внедрил то-то) - к кандидату имеет смысл присмотреться внимательнее.
    А дальше только очное собеседование - никаких скайпов и тестовых заданий.

    На собеседовании я обычно прошу выбрать из послужного списка какой-нибудь один проект (на усмотрение самого кандидата - наиболее крутой: в котором было найдено какое-нибудь особенно интересное решение, или использованы какие-нибудь крутые технологии, или решена какая-нибудь нетривиальная задача... короче, которым он сам гордится) и рассказать о нем подробнее, но, опять же, не в смысле, какие именитые были заказчики или как необъятен был бюджет, а в смысле, что он любимый в нем конкретно сделал, чему научился и чего добился. Обычно уже сам выбор достаточно показателен. (Если чел собеседуется, например, на синьера JEE, а в качестве темы выберет написанный в старших классах школы сайт на PHP, на котором была особенно удачная фотография кошки - это уже повод задуматься.)

    А дальше, по мере рассказа, начинаю задавать уточняющие вопросики (на вшивость): ага... тесты писали... а какое было покрытие? А как определяли? А в каком порядке выполнятся тесты из одного класса?.. Так, так... JBoss... а какая версия использовалась? Дескрипторы или аннотации? А что нового появилось в следующих версиях? А сервлеты вручную писали? ...ага, SOAP. А из каких трех частей состоит WSDL? А моки в SOAPUI делали? Ну, и далее - вглубь или вширь, по мере объема знаний кандидата.

    У такого подхода есть две стороны. Первая: если человеку есть чем гордиться, он начинает с горящими глазами грузить меня техническими подробностями, снимается ситуация стресса. Из режима "теста" мы плавно переходим в режим беседы на профессиональные темы. Если же начинает мямлить что-то про невероятную важность проекта и свою ключевую роль в нем, но на вопросы не может ответить, т.к. "этим он лично не занимался", а "эти решения принимали другие", то с ним очень быстро все становится понятно и беседу на этом можно заканчивать.

    И вторая: из резюме зачастую сложно даже предположить уровень "погружения" в отдельные технологии. В беседе удается точно выяснить предположительные сильные стороны кандидата и тогда уже задавать конкретные вопросы, позволяя ему раскрыть глубину познаний.

    Еще по поводу отдельных технологий, о которых заходит речь, прошу кандидата оценить свои познания в ней по пятибальной шкале "1 - первый раз слышу, 5 - эксперт". Для экспертов у меня заготовлены конкретные вопросы из жизни, как правило, примеры кода, иллюстрирующие какую-нибудь нетривиальную хреновину, которые я тут же достаю из папочки и предлагаю совместно разобрать. Эксперт в Яве - хорошо! Давай побеседуем о медели памяти, сборщиках мусора или кеше процессора. Эксперт в SQL - замечательно! Давай попробуем оптимизировать запрос. Эксперт в сетях - чудесно! Давай разберемся, почему падает вот этот долбаный сокет. Опять же, цель этого подхода - отнюдь не завалить самоуверенного кандидата, а именно понять, как человек мыслит, как ищет решения проблем, достаточно ли у него для этого знаний и опыта. Не беда, если кандидат погорячился с самооценкой... тут важно не знание ответа, а именно подход к решению проблемы (т.к. от синьера именно таки ожидается решение проблемы, а не констатация ее сложности).
    Ответ написан
    2 комментария
  • Чем отличается junior от middle? а Senior?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Вот как это выглядит с т.з. работодателя

    Джун
    - собеседование
    изъясняется исключительно на сленге (большую часть которого не может внятно объяснить), готов в одиночку за неделю написать новую ОС, или две - за полторы, если только для этого не придется учить ассемблер, несмотря на юный возраст уже обладатель прав на обе версии и один бэкап личного сайта с фотографией кошки в розовой рамке и знает, что синглтон - это абсолютное зло, хотя и не может написать его без ошибок.
    - испытательный срок
    долго мудохается с настройками рабочего места, которые регулярно слетают под тяжестью многотысячных плагинов, шелов и скринсейверов, донимает админов, находит две (орфографические) ошибки в документации проекта и один быстрый альтернативный способ сделать форк из SVN, после которого проект, к сожалению, не билдится не только у него, но и у всей команды. Берется все немедленно исправить с помощью другого чудотворного плагина, (неожиданный баг в котором приходится фиксить двум миддлам), после чего насильственно лишается рута, плагинов и шелов и начинает изучать проект под чутким контролем матерящихся миддлов.
    - работа
    научился билдить проект, писать тесты и коммитить, не роняя этим билд, понял смысл многих сленговых выражений, подружился с миддлами и админами, не путается в названиях ключевых технологий, радикально сократил число плагинов, удалил сайт с кошкой, работает.

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

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