Почему я никогда не вернусь из менеджмента в разработчики. Да все очень просто. Во-первых это деградация, полная. Ты с утра до вечера занимаешься однообразными задачами по написанию кода:
следишь за качеством архитектуры костыляешь чтоб побыстрому запустить новую фичу
следишь за тех долгом заводишь задачки на выпиливание костылей до которых никогда не дойдут руки
решаешь сложные задачи занимаешься перекладыванием джейсонов слева направо
следишь за трендами и новыми технологиями изучаешь новый фреймворк, который никогда не будешь применять
При этом твоя зарплата не растет и новую работу найти не так то просто. То есть растет, но не так быстро как хотелось бы. Компании проще нанять тыщу джунов с копайлотом, чем одного сеньора который сделает хорошую архитектуру, будет писать качественный, расширяемый, тестируемый и поддерживаемый код. На собеседованиях тебя будут долго мурыжить джуны задавая тупые вопросы "а что будет если скрестить бульдога с носорогом" глядя на тебя с насмешкой в глазах, в которой читается "ааа, не знаешь! а я - знаю! вот я тебя и поймал, никакой ты не сеньор, а врун джуновый!".
Ну и конечно же карьерный тупик. Через 20 лет работы инженером ты оказываешься перед жестоким выбором: либо засунуть свои 20 лет опыта в языке и фреймворке, которые уже не нужны рынку (привет COBOL) либо искать болото, в котором до сих пор используют некрофильские практики (привет COBOL).
Как я вас понимаю! А еще меня бесит когда в тех поддержку ждать на линии телефона 5 минут или еще дольше. Ведь мое время дорого стоит! А как было бы здорово иметь персонального менеджера: ты ему звонишь с вопросом днем и ночью и он сразу все решает в онлайне, ждать не надо. А если не решит - можно и матом его!
Я вот специально залогинился через 5 лет молчания чтобы ответить:
— офис должен быть многокомнатным для команд максимум до 5-7 человек
Думается что 5-7 это неверный критерий. Мне видится критерий «скрам-команда в своем офисе» более верным. Скрам команда обычно небольшая, чтобы накормить 2-мя пиццами :-)
Как правило наблюдал такой феномен когда вся пирамида эджайла после неудавшегося релиза приходила к разработчику и распинала его на эшафоте при этом никто из пирамиды сверху не ответил за неверные сроки, за не правильную идею, за не точную постановку, за не верный дизайн и многое другое — потому что нет этого в эджайле по-определению :) это технология управления РЕСУРСАМИ а не людьми.
Вся пирамида аджайла как раз устроена таким образом, чтобы:
1) контролировать фокус. Я заметил что после 3-х недель фокус людей начинает смещаться в сторону от первоначальной идеи. Как правило после 4-х недель от первоначальной идеи не остается и следа: программист сам придумывает себе задачу, сам творчески с ней справляется и бодро рапортует о проделанной работе. В большинстве случаев та проблема которую он себе придумал не имеет никакого практического значения: либо экономия 1% ресурсов, либо решение несуществующей проблемы.
2) Контролировать прогресс: ежедневные стендапы направлены на то чтобы контролировать прогресс и не терять фокуса проблемы. Если ваши задачи разбиты на 2-х дневные участки, то вы легко сможете контролировать прогресс, а значит раньше отреагировать на возможные проблемы. Пример из жизни: разработчик потратил полтора дня на разворачивания environment для имплементации функции. Моя вина — на стендах он про это молчал. В результате вместо 4-х часов на задачу было потрачено 2 дня. Как инсайт — никого не уволили, договорились что на стендапах рано рапортуем о проблемах. Кстати, ретроспективы для этого и предназначены, чтобы выявлять внутренние проблемы, мешающие работе.
3) Груминг (или декомпозиция) предназначены для того, чтобы все участники процесса получили правильное понимание того, что разрабатываем. Для этого на груминг собираются не только программисты, но и продуктологи. Продуктологи рассказывают что они хотят получить, а программисты предлагают простые решения этой проблемы. Там же легко выявить «неточную постановку» просто потому, что мы неточную постановку в разработку не берем (у нас встроено определение «ready for development» без формального соблюдения которого задача в работу не идет).
Из преведенной мною цитаты я могу сделать вывод, что, к сожалению, вы попали как раз на карго культ скрама, а не на скрам. Скрам — это как раз про людей, про то как они взаимодействуют, как они планируют свое время (а вот это уже ресурс) и договоренность о том что же они делают. Для меня скрам — это механизм самоуправления в команде, когда команда сама принимает решения о том что и как делать.
— в коллективе где есть хоть 2 разработчика 3м обязательно должен быть психолог!
меня поражает детсадовский подход в так называемом карьерном росте разработчиков во всех IT компаниях — типа из разработчика в тимлиды. Да ни за что! без вердикта психолога о том что человек по своей психологии является лидером и руководителем ни в коем случае такое делать нельзя — иначе потом горе тому коллективу.
В тех случаях когда тимлида назначают как правило так и происходит. В моем опыте лучшими тимлидами становятся внутренние лидеры — те, кого выбирает команда. Именно поэтому я никогда не нанимаю сразу в тимлиды. Беру разработчиком. Показал лидерство, уважение команды — велкам, промутим в тимлиды после испытательного срока. Не показал — сорян. Те кто ориентирован на карьерный рост в быструю сразу отсеиваются. Те кто чего-то стоит и уверены в себе — те соглашаются.
В автомагазинах есть антизапотевающая жидкость. Ею протирают лобовое стекло чтобы не выпадала роса. Можно спросить у друзей-горнолыжников, чем они протирают свои очки.
Фокус промахнулся. Либо автор лажанул либо камера — этого я не знаю. При ручной фокусировке такого промаха не сделать.
Предыдущая фотография в серии с правильным фокусом. Эта — технический брак, к сожалению.
Отличный портрет. Можно узнать ТТХ техники и параметры съемки (меня в первую очередь интересует диафрагма и не «приведенное фокусное» расстояние, размер матрицы)
Извините, но… Я просто в шоке от такого ответа…
Глубина резкозти — это один из немногих доступных фотографу способов передать объем на снимке.
Хотя, если всю жизнь щелкать на мыльницу, то ГРИП особо не нужен и даже вреден: становятся видны огрехи автофокуса.
И да, макро и портретник — это разные объективы. Один для макросъемки и он должен быть суперрезким. Второй — для портретов и он дожен быть мягким. Снимать портреты макрообъективом — это моветон. Ваши модели будут жаловаться на каждый прыщик на коже.
Макро — это идеальное применение для системы 3/4. Для макро важны большая глубина резкозти, сверхчеткость картинки и контраст.
Извините, в приведенных вами семплах не увидел примеров фотографий с малым ГРИП. Размытый задний план это еще не малый ГРИП. Вы попробуйте открыть дырку и снять лицо человека так, чтобы глаз был в фокусе, а ухо — уже нет. Причем заметно нет.
Кстати, у классических зеркалок далеко не самый удобный и быстрый способ наведения на резкость, так как нужно на глаз искать где самая высокая контрастность
Уважаемый, Вы когда-нибудь снимали неавтофокусной камерой?
Вы вообще хоть раз в руки зеркалку брали? Вы в одном абзаце умудрились сделать 3 фактические ошибки.
1) резкость и контрастность разные вещи. Кадр может быть контрастным, но не резким.
2) мне не нужно искать где область резкости. При съемке я сам выбираю то место, на котором хочу сфокусироваться. Глазом. Мне не нужно при этом водить органами управления сдвигая «фокус пикинг» точку. Мне не нужно водить органами управления для того, чтобы выбрать точку фокусировки. Я просто смотрю туда где хочу сфокусироваться и вращаю кольцо фокусировки. Оно УЖЕ под пальцами именно в том месте где я поддерживаю объектив снизу против тряски.
3) Микропризмы кстати не самый удобный способ фокусировки. Сдвинутый центр гораздо точнее.
4) Дальномерки менее точны при ручной фокусировке, так как во-первых при смене объектива необходимо менять дальномер, а во-вторых в видоискателе вы видите совсем не то, что будет на кадре. Дальномерка позволяет «примерно прицелиться». С помощью зеркалки точность прицеливания 100%, что обеспечивается конструкцией камеры TTL — Through The Lense. Вы видите в видоискателе именно ту картинку которая попадет в кадр.Это особенно ярко выражено при съемке с малого расстояния/макро.
Мне для «репортажки» экран или видоискатель вообще не нужен: при желании могу снять от пояса не сильно промахнувшись по кадрированию. Иногда как только начинаешь целиться в кого-то — сразу меняют сцену, выражение лица и т.д.
Когда-то на тренингах по корпоративному управлению учили всегда уточнять задачу, пересказав ее своими словами. Стараюсь использовать в работе с заказчиками — сильно помогает. А вот если уточняющих вопросов от исполнителя не поступило — повод задуматься и постараться их вытянуть…
НО степень детализации задачи должна зависеть от уровня исполнителя. Кому-то достаточно сказать «поищи статистичекие анализаторы» и он в контексте проблемы сразу поймет о чем речь, а кому-то потребуется пошаговый алгоритм.
Если в коллективе есть менеджер, то постановка задачи так, чтобы она не подразумевала многоликости трактовки — это его работа.
Не все задачи поддаются 100% формализации, все равно будут темные области. Как бы вы ни расписывали задачу — все равно найдется один-два-три ключевых момента, которые будут поняты неправильно.
Постановка цели должна в первую очередь опираться на исполнителя. Кому-то достаточно сказать «поищи статистические анализаторы» и он в контексте общей проблемы поймет что нужно сделать, а другому нужен пошаговый алгоритм.
Но для того чтобы избежать проблемы недопонимания — исполнитель обязательно должен уточнить правильно ли он понял задачу, пересказав ее своими словами. Я когда разговариваю с заказчиками стараюсь делать именно так и хотел бы чтобы члены моей команды поступали так же.
А вот если не последовало уточняющих вопросов или пересказа — вот тогда менеджеру 100% нужно вмешиваться и вытаскивать из исполнителя клещами, как тот понял задачу. Проблемы как правило возникают именно здесь.
<sarcasm>
Почему я никогда не вернусь из менеджмента в разработчики. Да все очень просто. Во-первых это деградация, полная. Ты с утра до вечера занимаешься однообразными задачами по написанию кода:
следишь за качеством архитектурыкостыляешь чтоб побыстрому запустить новую фичуследишь за тех долгомзаводишь задачки на выпиливание костылей до которых никогда не дойдут рукирешаешь сложные задачизанимаешься перекладыванием джейсонов слева направоследишь за трендами и новыми технологиямиизучаешь новый фреймворк, который никогда не будешь применятьПри этом твоя зарплата не растет и новую работу найти не так то просто. То есть растет, но не так быстро как хотелось бы. Компании проще нанять тыщу джунов с копайлотом, чем одного сеньора который сделает хорошую архитектуру, будет писать качественный, расширяемый, тестируемый и поддерживаемый код. На собеседованиях тебя будут долго мурыжить джуны задавая тупые вопросы "а что будет если скрестить бульдога с носорогом" глядя на тебя с насмешкой в глазах, в которой читается "ааа, не знаешь! а я - знаю! вот я тебя и поймал, никакой ты не сеньор, а врун джуновый!".
Ну и конечно же карьерный тупик. Через 20 лет работы инженером ты оказываешься перед жестоким выбором: либо засунуть свои 20 лет опыта в языке и фреймворке, которые уже не нужны рынку (привет COBOL) либо искать болото, в котором до сих пор используют некрофильские практики (привет COBOL).
</sarcasm>
Как я вас понимаю! А еще меня бесит когда в тех поддержку ждать на линии телефона 5 минут или еще дольше. Ведь мое время дорого стоит! А как было бы здорово иметь персонального менеджера: ты ему звонишь с вопросом днем и ночью и он сразу все решает в онлайне, ждать не надо. А если не решит - можно и матом его!
/sarcasm
Думается что 5-7 это неверный критерий. Мне видится критерий «скрам-команда в своем офисе» более верным. Скрам команда обычно небольшая, чтобы накормить 2-мя пиццами :-)
Вся пирамида аджайла как раз устроена таким образом, чтобы:
1) контролировать фокус. Я заметил что после 3-х недель фокус людей начинает смещаться в сторону от первоначальной идеи. Как правило после 4-х недель от первоначальной идеи не остается и следа: программист сам придумывает себе задачу, сам творчески с ней справляется и бодро рапортует о проделанной работе. В большинстве случаев та проблема которую он себе придумал не имеет никакого практического значения: либо экономия 1% ресурсов, либо решение несуществующей проблемы.
2) Контролировать прогресс: ежедневные стендапы направлены на то чтобы контролировать прогресс и не терять фокуса проблемы. Если ваши задачи разбиты на 2-х дневные участки, то вы легко сможете контролировать прогресс, а значит раньше отреагировать на возможные проблемы. Пример из жизни: разработчик потратил полтора дня на разворачивания environment для имплементации функции. Моя вина — на стендах он про это молчал. В результате вместо 4-х часов на задачу было потрачено 2 дня. Как инсайт — никого не уволили, договорились что на стендапах рано рапортуем о проблемах. Кстати, ретроспективы для этого и предназначены, чтобы выявлять внутренние проблемы, мешающие работе.
3) Груминг (или декомпозиция) предназначены для того, чтобы все участники процесса получили правильное понимание того, что разрабатываем. Для этого на груминг собираются не только программисты, но и продуктологи. Продуктологи рассказывают что они хотят получить, а программисты предлагают простые решения этой проблемы. Там же легко выявить «неточную постановку» просто потому, что мы неточную постановку в разработку не берем (у нас встроено определение «ready for development» без формального соблюдения которого задача в работу не идет).
Из преведенной мною цитаты я могу сделать вывод, что, к сожалению, вы попали как раз на карго культ скрама, а не на скрам. Скрам — это как раз про людей, про то как они взаимодействуют, как они планируют свое время (а вот это уже ресурс) и договоренность о том что же они делают. Для меня скрам — это механизм самоуправления в команде, когда команда сама принимает решения о том что и как делать.
В тех случаях когда тимлида назначают как правило так и происходит. В моем опыте лучшими тимлидами становятся внутренние лидеры — те, кого выбирает команда. Именно поэтому я никогда не нанимаю сразу в тимлиды. Беру разработчиком. Показал лидерство, уважение команды — велкам, промутим в тимлиды после испытательного срока. Не показал — сорян. Те кто ориентирован на карьерный рост в быструю сразу отсеиваются. Те кто чего-то стоит и уверены в себе — те соглашаются.
Предыдущая фотография в серии с правильным фокусом. Эта — технический брак, к сожалению.
Ну, в общем камера (точнее размер матрицы) и линза (точнее ее апертура) говорят за себя сами.
Извините, но… Я просто в шоке от такого ответа…
Глубина резкозти — это один из немногих доступных фотографу способов передать объем на снимке.
Хотя, если всю жизнь щелкать на мыльницу, то ГРИП особо не нужен и даже вреден: становятся видны огрехи автофокуса.
И да, макро и портретник — это разные объективы. Один для макросъемки и он должен быть суперрезким. Второй — для портретов и он дожен быть мягким. Снимать портреты макрообъективом — это моветон. Ваши модели будут жаловаться на каждый прыщик на коже.
Макро — это идеальное применение для системы 3/4. Для макро важны большая глубина резкозти, сверхчеткость картинки и контраст.
Уважаемый, Вы когда-нибудь снимали неавтофокусной камерой?
Вы вообще хоть раз в руки зеркалку брали? Вы в одном абзаце умудрились сделать 3 фактические ошибки.
1) резкость и контрастность разные вещи. Кадр может быть контрастным, но не резким.
2) мне не нужно искать где область резкости. При съемке я сам выбираю то место, на котором хочу сфокусироваться. Глазом. Мне не нужно при этом водить органами управления сдвигая «фокус пикинг» точку. Мне не нужно водить органами управления для того, чтобы выбрать точку фокусировки. Я просто смотрю туда где хочу сфокусироваться и вращаю кольцо фокусировки. Оно УЖЕ под пальцами именно в том месте где я поддерживаю объектив снизу против тряски.
3) Микропризмы кстати не самый удобный способ фокусировки. Сдвинутый центр гораздо точнее.
4) Дальномерки менее точны при ручной фокусировке, так как во-первых при смене объектива необходимо менять дальномер, а во-вторых в видоискателе вы видите совсем не то, что будет на кадре. Дальномерка позволяет «примерно прицелиться». С помощью зеркалки точность прицеливания 100%, что обеспечивается конструкцией камеры TTL — Through The Lense. Вы видите в видоискателе именно ту картинку которая попадет в кадр.Это особенно ярко выражено при съемке с малого расстояния/макро.
До такого я еще не дорос…
НО степень детализации задачи должна зависеть от уровня исполнителя. Кому-то достаточно сказать «поищи статистичекие анализаторы» и он в контексте проблемы сразу поймет о чем речь, а кому-то потребуется пошаговый алгоритм.
Не все задачи поддаются 100% формализации, все равно будут темные области. Как бы вы ни расписывали задачу — все равно найдется один-два-три ключевых момента, которые будут поняты неправильно.
Постановка цели должна в первую очередь опираться на исполнителя. Кому-то достаточно сказать «поищи статистические анализаторы» и он в контексте общей проблемы поймет что нужно сделать, а другому нужен пошаговый алгоритм.
Но для того чтобы избежать проблемы недопонимания — исполнитель обязательно должен уточнить правильно ли он понял задачу, пересказав ее своими словами. Я когда разговариваю с заказчиками стараюсь делать именно так и хотел бы чтобы члены моей команды поступали так же.
А вот если не последовало уточняющих вопросов или пересказа — вот тогда менеджеру 100% нужно вмешиваться и вытаскивать из исполнителя клещами, как тот понял задачу. Проблемы как правило возникают именно здесь.