Конечно для начальства было бы ещё удобнее проводить его чуть ли не каждый день… Но раз в месяц «Performance review»? Seriously? Тут раз в год его проходишь и тошно. Вообще бы убрал этот пережиток hr.
А фидбек должен начальник давать, тимлид, старший инженер. Раз в две недели в течение 30 минут 1:1. Old school, как говориться.
Руководитель в айти это прежде всего младший инженер(тестировщик, админ)-старший- тим лид. Ну или та же линейка прогресса только из product. Поэтому большинство описаных в статье знаний уже должно быть в его багаже опыта.
В корне несогласен с автором статьи по поводу сертификаций и платных курсов как способ научиться руководить. Скорее как способ потратить свои деньги на тех, кто не руководил ни дня и пытается на вас заработать себе на жизнь. Такая же точка зрения у меня и на высшее образование. Преподователи которые сидят в учебных заведениях, чаще всего не проработали ни дня в айти компаниях, не смогли или не захотели устроиться да так и остались в своих университетах. Мне совсем не ясно чему же они там учат.
От себя могу порекомендовать три книги, которые мне лично очень помогли и главное, они от реальных, успешных руководителей, и дают практические советы в отличие от всяких курсов:
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) — книгу написали аж в 1975 году по-моему, но она жо сих пор очень актуальна для айти. Прочитав её, я понял, что ошибался когда считал свои проблемы в управлении проектами уникальными. Оказалось еще 30 лет назад умные люди уже сталкивались и придумали эффективные способы решения. Пример такой проблемы описанной в книге — добавление человекоресурсов к проекту который запаздывает по срокам чаще всего не приведёт к ускорению сроков выпуска.
Rapid Development: Taming Wild Software Schedules — очень много примеров проблем управления проектами из жизни, и как с ними боролись.
Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams — эта больше психологию управления, интересные фишки руководства именно людьми.
По факту «расследование» притянуто за уши. «Среди очень немногих доменов, зарегистрированных с этими китайскими номерами, которые не были замечены в запуске вредоносных программ, есть веб-сайт под названием «cubehost[dot]biz», который был зарегистрирован в сентябре 2013-го на 28-летнего Артема Тверитинова из города Пермь, Россия.» Самое слабое место данной статьи. Кто остальные «немногие» из того списка? Почему именно cubehost послужил стартом для расследования?
Я лично покинул бы с поднятым средним пальцем, проект, где меня «успешный и эффективный junior CTO на пятом курсе института» попросил бы работать на выходных или праздниках. Пусть работает с такими же успешными и эффективным студентами сокурсниками.
Кроме СНГ где-то еще популярен данный «продукт»? Я нигде не встречал, за 12 лет проработав в Европе, Сша, Австралии, Сингапуре…
Везде пытаются оптимизировать раб. процессы, но никак не слежку за работниками устраивать. Стыд и срам.
Эффективность энтерпрайз проекта на мой взгляд, прежде всего напрямую зависит от правильной иерархии и насколько хорошо каждый участник понимает своё в ней место.
Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.
Какая-то непонятная рефлексия. «Вспоминайте о своих слабых местах» блаблабла… Единственное, что достойно уважения, не опустил руки и продолжает работать
Желтушная статейка.
Ребята журнализды, 21 век на дворе, реальность такова, что мы будем смотреть порно, не расставаться со смартфонами, и играть в интернете. И отклонения скорее у тех, кто этого не делает не идя в ногу со временем. 100 лет назад считалось отклонением ездить на велосипеде на работу и женщине в брюках ходить.
Говорить, что среднестатистический человек нашего времени депрессивен только потому что «в 80-е так не жили» — верх идиотизма.
Статья вполне годная для новичков. Автор оттачивает навыки гуглопоиска, что самое критичное для айтишника, так держать :)
Заглянул в профиль линкедина и немножко улыбнулся, не в обиду за мой анализ(издержки профессии):
QA Engineer(1 year 1 month)
Senior QA Engineer(1 year 1 month) — внезапно через год работы уже senior :D
QA Automation Lead((4 months)) — еще через год аж лидер автоматизации)
Project Manager(6 months) — походу рановато для автоматизации после 2-х лет в ай ти :D
Test Lead(5 months) — Test Lead. Хотя автор пишет что он там «Junior QA Engineer в крупной компании».
В общем язык подвешен и на интервью не теряется :) Я бы взял младшим тестировщиком, но никак не лидером автоматизации уж прости :)
>Пожалуй, самое важное для успешного собеседования по программированию — хорошая подготовка. Лучше всего практиковаться со стандартными вопросами снова и снова, пока вы не выучите их назубок.
Самое важное для успешного собеседования по программированию:
1. Вовремя распознать на интервью куда вы попали. Туда где вы будете работать или распозновать полиндромы. Если человек не прошерстил ваш профиль в linkedin, не задавал подробных вопросов, что делали на прошлых работах, и если из вышесказанного интервьюер не понимает, насколько вы компетентны, а продолжает вас звать к доске решать полиндромы — бегите оттуда со всех ног.
2. Покинуть страну, где в 90% компаний верстают сайты, аутсорсят на запад за гроши, и при этом требуют знания профессора математики, а платят копейки, заставляют стоять у доски в 8 часов вечера ибо дедлайн «аутсорса за гроши». В общем покиньте Африку и переезжайте к белым людям. В ту же Чехию из статьи выше.
2.
А фидбек должен начальник давать, тимлид, старший инженер. Раз в две недели в течение 30 минут 1:1. Old school, как говориться.
В корне несогласен с автором статьи по поводу сертификаций и платных курсов как способ научиться руководить. Скорее как способ потратить свои деньги на тех, кто не руководил ни дня и пытается на вас заработать себе на жизнь. Такая же точка зрения у меня и на высшее образование. Преподователи которые сидят в учебных заведениях, чаще всего не проработали ни дня в айти компаниях, не смогли или не захотели устроиться да так и остались в своих университетах. Мне совсем не ясно чему же они там учат.
От себя могу порекомендовать три книги, которые мне лично очень помогли и главное, они от реальных, успешных руководителей, и дают практические советы в отличие от всяких курсов:
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) — книгу написали аж в 1975 году по-моему, но она жо сих пор очень актуальна для айти. Прочитав её, я понял, что ошибался когда считал свои проблемы в управлении проектами уникальными. Оказалось еще 30 лет назад умные люди уже сталкивались и придумали эффективные способы решения. Пример такой проблемы описанной в книге — добавление человекоресурсов к проекту который запаздывает по срокам чаще всего не приведёт к ускорению сроков выпуска.
Rapid Development: Taming Wild Software Schedules — очень много примеров проблем управления проектами из жизни, и как с ними боролись.
Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams — эта больше психологию управления, интересные фишки руководства именно людьми.
Везде пытаются оптимизировать раб. процессы, но никак не слежку за работниками устраивать. Стыд и срам.
Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.
Ребята журнализды, 21 век на дворе, реальность такова, что мы будем смотреть порно, не расставаться со смартфонами, и играть в интернете. И отклонения скорее у тех, кто этого не делает не идя в ногу со временем. 100 лет назад считалось отклонением ездить на велосипеде на работу и женщине в брюках ходить.
Говорить, что среднестатистический человек нашего времени депрессивен только потому что «в 80-е так не жили» — верх идиотизма.
Заглянул в профиль линкедина и немножко улыбнулся, не в обиду за мой анализ(издержки профессии):
QA Engineer(1 year 1 month)
Senior QA Engineer(1 year 1 month) — внезапно через год работы уже senior :D
QA Automation Lead((4 months)) — еще через год аж лидер автоматизации)
Project Manager(6 months) — походу рановато для автоматизации после 2-х лет в ай ти :D
Test Lead(5 months) — Test Lead. Хотя автор пишет что он там «Junior QA Engineer в крупной компании».
В общем язык подвешен и на интервью не теряется :) Я бы взял младшим тестировщиком, но никак не лидером автоматизации уж прости :)
Самое важное для успешного собеседования по программированию:
1. Вовремя распознать на интервью куда вы попали. Туда где вы будете работать или распозновать полиндромы. Если человек не прошерстил ваш профиль в linkedin, не задавал подробных вопросов, что делали на прошлых работах, и если из вышесказанного интервьюер не понимает, насколько вы компетентны, а продолжает вас звать к доске решать полиндромы — бегите оттуда со всех ног.
2. Покинуть страну, где в 90% компаний верстают сайты, аутсорсят на запад за гроши, и при этом требуют знания профессора математики, а платят копейки, заставляют стоять у доски в 8 часов вечера ибо дедлайн «аутсорса за гроши». В общем покиньте Африку и переезжайте к белым людям. В ту же Чехию из статьи выше.
2.