Comments 39
Не всем работодателям нужны узкоспециализированные специалисты. Кадровая политика и подход к управлению в нас, естественно, отличается от западного. И просто говорить «там так делают и у нас надо» — неверно совершенно.
Поэтому, эти управленцы в текущей ситуации с точки зрения заказчиков, финансовой ситуации в фирме, ситуации на рынке кадров на самом деле могут оказать правы, а вы — просто слишком высокомерный разработчик, которому лень приобретать знания из новой для себя области. У них в глобальном плане всегда больше информации, чем у вас.
Ничего ни про кого конкретно не утверждаю. Просто есть другой взгляд и есть сравнительно обоснованные аргументы в пользу и такого подхода. И, возможно, он ничуть не хуже «стандартного».
Поэтому, эти управленцы в текущей ситуации с точки зрения заказчиков, финансовой ситуации в фирме, ситуации на рынке кадров на самом деле могут оказать правы, а вы — просто слишком высокомерный разработчик, которому лень приобретать знания из новой для себя области. У них в глобальном плане всегда больше информации, чем у вас.
Ничего ни про кого конкретно не утверждаю. Просто есть другой взгляд и есть сравнительно обоснованные аргументы в пользу и такого подхода. И, возможно, он ничуть не хуже «стандартного».
1) Я не разработчик :-)
2) Разумеется капитализм желает получить максимальную прибыль. Идеальный случай — ничего людям не заплатить, заставив работать 24 в сутки в течение года.
Я в статье попытался обрисовать ситуацию, в которую попадает талантливый разработчик в нашей стране. Хотя тут уже начали, хотя бы в медицине понимать, что нельзя поручить проктологу лечить у пациента кариес — надеюсь в области IT понимание придет со временем тоже.
2) Разумеется капитализм желает получить максимальную прибыль. Идеальный случай — ничего людям не заплатить, заставив работать 24 в сутки в течение года.
Я в статье попытался обрисовать ситуацию, в которую попадает талантливый разработчик в нашей стране. Хотя тут уже начали, хотя бы в медицине понимать, что нельзя поручить проктологу лечить у пациента кариес — надеюсь в области IT понимание придет со временем тоже.
Мне кажется в России у талантливого разработчика 2 пути, фактически: или самому создавать бизнес или уезжать отсюда. Бывают исключения, но тратить своё время на поддержку говнокода, борьбу с менеджерами и всякое такое прочее — довольно нерационально. Ибо говнокод возникает чаще всего из-за принципиальной и непреодолимой тупости и лени писавшего, как и «рыночный» менеджмент.
Речь в статье не об этом, а о том, что когда PHPшнику говорят за неделю выучить Javascript, а C++нику — быстренько наваять интерфейс на незнакомом ему тулките, это и есть натуральная профанация.
И причём тут запад? При организации рабочего процесса нужно руководствоваться здравым смыслом, который на западе такой же, как у нас или в Африке. Просто очень много управленцев в IT вообще не понимают, чем управляют — они банально не в теме, они никогда не программировали и даже не видели, как это происходит. А это не пельмени лепить, знаете ли.
И причём тут запад? При организации рабочего процесса нужно руководствоваться здравым смыслом, который на западе такой же, как у нас или в Африке. Просто очень много управленцев в IT вообще не понимают, чем управляют — они банально не в теме, они никогда не программировали и даже не видели, как это происходит. А это не пельмени лепить, знаете ли.
Здравый смысл таков. Надо наваять тут же интерфейс. Делать этого некому. И не важно почему. Не важно потому, что надо сделать здесь и сейчас, а не проводить работу над ошибками. И просят об этом того, кому больше всего доверяют и в чьих мозгах больше всего уверенны. Где конкретно тут ошибка?
Я прекрасно знаю что такое программирование. С 7 класса этим занимаюсь, а сейчас этим на жизнь зарабатываю. И меня совершенно не беспокоит, когда, допустим просят помочь с настройкой сервера, т.к. а данный момент у нас админа нет. Меня не беспокоит когда просят написать письмо так, чтобы с минимальными правками можно было отослать его заказчику, ибо в данный момент у меня время есть, а у того, кто контактирует с заказчиком — нет.
Ниже в комментариях пишут, что менеджеры «безразличны к будущему компании, в которой работают». Скорее всего это так и есть. Более того: с программистами, уверен, ситуация схожа. И это так, потому что ситуация в России нестабильна. Очень мало кто готов работать на будущее, а не хапать здесь и сейчас.
Программистам, да и вообще всем, надо понять одну простую вещь: мир не крутиться вокруг них. Лично мне на осознание этого потребовалось три года и дважды поменять работу.
Я прекрасно знаю что такое программирование. С 7 класса этим занимаюсь, а сейчас этим на жизнь зарабатываю. И меня совершенно не беспокоит, когда, допустим просят помочь с настройкой сервера, т.к. а данный момент у нас админа нет. Меня не беспокоит когда просят написать письмо так, чтобы с минимальными правками можно было отослать его заказчику, ибо в данный момент у меня время есть, а у того, кто контактирует с заказчиком — нет.
Ниже в комментариях пишут, что менеджеры «безразличны к будущему компании, в которой работают». Скорее всего это так и есть. Более того: с программистами, уверен, ситуация схожа. И это так, потому что ситуация в России нестабильна. Очень мало кто готов работать на будущее, а не хапать здесь и сейчас.
Программистам, да и вообще всем, надо понять одну простую вещь: мир не крутиться вокруг них. Лично мне на осознание этого потребовалось три года и дважды поменять работу.
Проблема, по-моему, не в том, что просят/требуют наваять интерфейс, настроить сервер или сделать кроссбраузерную вёрстку, а в том, что дают на это времени немногим больше, чем это займёт у специалиста именно в этой области, не закладывая никаких резервов и рисков на случай что по каким-то причинам программист «спотыкнётся на ровном месте», столкнётся с проблемой, решение которой настолько очевидно, что о нём даже гугл не знает, да и просто начнёт изобретать велосипед, не зная о готовых библиотеках/фреймворках. А потом ещё искренне недоумевают «как же так, под винду ты это сделал за два дня, а под линукс уже неделю не можешь хоть что-то похожее нарисовать»
А это — не проблема. Это — жизнь. Чтобы не плодить конфликты, надо взять и объяснить человеческим языком откуда взялось время 4х. И ничего в этом сложного нет.
И ничего в этом сложного нет.
Сложно объяснить нет ничего. Тебя поймут и скажут что ты прав, но сдавать нужно через неделю, поэтому сделай что-нибудь. Сделаешь плохо — конечно ты виноват, ведь завалены бизнес интересы.
Вы всё верно говорите, однако тот факт, что вы сейчас нашли себе место работы, где у вас reasonable management не означает, что он такой везде.
Дважды поменять работу — это нормально. Рынок труда — это рынок. Программист на нем такой же полноправный участник как и другие.
Всё это справедливо в любой области деятельности.
Как на 10 программистов приходится один, который пишет комментарии в коде даже себе «будущему», также и на 10 менеджеров приходится один, который не только соображает в техническом плане, но и делает дело, а не создает видимость.
Как на 10 программистов приходится один, который пишет комментарии в коде даже себе «будущему», также и на 10 менеджеров приходится один, который не только соображает в техническом плане, но и делает дело, а не создает видимость.
Блин, даже студенты с улицы работают за пятьсот баксов!
Был недавно на конференции РИТ-2011 в Москве. Там был представитель одной _весьма_ известной медиа-поисковой компании (без имён уж), так вот — с него по вашей статье (подписываюсь лично под каждым словом) — портрет писать можно. Начнём с того, что сей товарищ высказывался весьма радикально против набора студентов (по его словам, это не оправдывает затрат). На другой день в течении 45 минут от него же все участники выслушивали рассуждения на тему «Да я найму 50 быдлокодеров, которые это напишут за неделю».
Так и здесь. Я считаю, что менеджеры, которые не заинтересованы в развитии собственных программистов — как максимум — глупы, а как минимум — безразличны к будущему компании, в которой работают (и мои мысли подтверждает книга Peopleware: Productive Projects and Teams авторов Tom DeMarco, Timothy Lister).
Так и здесь. Я считаю, что менеджеры, которые не заинтересованы в развитии собственных программистов — как максимум — глупы, а как минимум — безразличны к будущему компании, в которой работают (и мои мысли подтверждает книга Peopleware: Productive Projects and Teams авторов Tom DeMarco, Timothy Lister).
Мне кажется, что еще один стереотип о «молодости программиста» развился ввиду того, что сама отрасль молодая.
Ну т.е. после ВУЗа проще окунуться в работу программиста, чем переучиваться. Поэтому 10 лет назад большая часть программистов и была действительно молодыми ребятами. Теперь они повзрослели, набрались опыта, но стереотипы остались…
Ну т.е. после ВУЗа проще окунуться в работу программиста, чем переучиваться. Поэтому 10 лет назад большая часть программистов и была действительно молодыми ребятами. Теперь они повзрослели, набрались опыта, но стереотипы остались…
И согласен, и не согласен.
Согласен с тем, что нельзя специалиста по проектированию баз данных заставлять верстать кроссбраузерно, да так чтобы под IE выглядело прилично. Но при этом стоит понимать, что спец по PHP впринципе на пути своего становления способен грамотно сверстать страницу, никто не спорит что это займёт гораздо больше времени, но иногда бывают случаи, когда работа есть, а денег на привлечение стороннего специалиста нет. Тут конечно должен всё объяснить менеджер, почему он привлекает программиста к вёрстке, то есть дать понять, что у команды иного выхода нет, но если программист знает лучший выход пусть предложит. То есть ПМ не должен просто ставить задачу, он должен всё разъяснить.
Не согласен с тем что разработчики должны работать медленнее, мы все живём в рыночных условиях и кто быстрее выпустит продукт на рынок (пусть он даже будет как решето в плане безопасности и надёжности работы), тот и выиграл. Поэтому есть такая штука дедлайн, который реально надо соблюдать. То есть если ПМ говорит ведущему программисту: «Вася, у тебя на разработку вот этих модулей ровно месяц.», он это говорит не потому что хочет насолить Васе и его команде, или не потому что ни хрена не понимает в разработке. Он говорит так, потому что других сроков нет, и в 99% случаев делите тот срок который вам дал ПМ на 5 и получите тот срок, за который хотел работодатель чтобы вы всё сделали. А также не забывайте что у проекта есть не только программисты, есть концептологи, проектировщики, дизайнеры, верстальщики, админы, системные архитекторы, копирайтеры, спецы по юзабилити, рекламщики, менеджеры по продажам и туева куча других специальностей. ПМ должен знать и понимать работу каждого из них. То есть помимо работы Васи и его команды, ПМ должен понимать и знать работу ещё около 20 специальностей, включая определённые специализации этих специальностей. А ещё он должен знать свою работу в совершенстве. А ещё он в отличии от Васи должен обладать как гуманитарным, так и техническим складом ума. Он просит вас делать всё быстрее, потому что остальные люди не работают, а ждут когда вы сделаете определённую работу. Он рад бы чтобы проект был весь задокументирован, код был идеальным и вообще ни к чему нельзя было придраться, но это не художественная академия, чтобы выверять каждый штрих. Это бизнес, где большую роль играет скорость работы. В 99% случаев ПМ, ы это не менее, а порой даже и более творческие люди чем средний программист. В 60% случаев ПМ в IT раньше занимался программированием (в той или иной степени). Не надо обижаться на него за то что он вам ставит задачи и требует их исполнения в поставленный срок. Если вы не способны с ней справится — говорите сразу. Только не надо говорить ему о том, что вы не в состоянии сейчас определить сколько времени и сил понадобится на задачу и хватит ли вам их, если это действительно так — идите курит бамбук, вы не ведущий программист, и даже не программист, просто кодер. Я очень много работаю с хорошими прогерами и сам раньше занимался программированием — я сам заранее думаю сколько по срокам займёт подобная задача у моей команды и в 80% случаев всё сходится практически день в день. Ни разу не было чтобы я ошибся более чем на неделю (неделя в рамках 4 месяцев). Если вы хотите применять инновационные техники и методы, круто, но идите работать в исследовательский отдел какой-нибудь крупной компании (IBM, Microsoft, Google, etc.), но здесь, в жёстких условиях бизнеса, очень редко предоставляется возможность заняться инновациями.
В ообщем — не стоит считать ПМ, ов своими врагами, потому что они не понимают досконально суть вашей работы или ставят, как вам кажется, не те задачи с не теми сроками. Вы команда, братство, семья, да просто ахуенные ребята. Вы вместе выполняете одну задачу. По своему опыту скажу (я правда пить бросил уже давно) — сходите в бар всей командой, нажритесь до ужаса, а потом пойдите и начните выеживаться на банду байкеров. Вот тогда, после этого, вам будет что вспомнить и вы уже будете чувствовать себя единым целым. Когда ты знаешь, что вот Серёга парень хороший, но слабенький и не сможет уделать 5 байкеров одной левой и ты прикрываешь его, беря огонь на себя, или видя как ПМ разделывается с лидером байкеров, пытаетесь выбить тех, кто ему хочет помешать. Это реально весело:))) Работайте как единый механизм, создайте культ своей команды, считайте себя элитой, да всё что угодно делайте чтобы сплотится. Но никогда не устраивайте срач внутри команды. Если команда вас не устраивает, это не повод изменять команду, это повод уйти из этой команды.
Согласен с тем, что нельзя специалиста по проектированию баз данных заставлять верстать кроссбраузерно, да так чтобы под IE выглядело прилично. Но при этом стоит понимать, что спец по PHP впринципе на пути своего становления способен грамотно сверстать страницу, никто не спорит что это займёт гораздо больше времени, но иногда бывают случаи, когда работа есть, а денег на привлечение стороннего специалиста нет. Тут конечно должен всё объяснить менеджер, почему он привлекает программиста к вёрстке, то есть дать понять, что у команды иного выхода нет, но если программист знает лучший выход пусть предложит. То есть ПМ не должен просто ставить задачу, он должен всё разъяснить.
Не согласен с тем что разработчики должны работать медленнее, мы все живём в рыночных условиях и кто быстрее выпустит продукт на рынок (пусть он даже будет как решето в плане безопасности и надёжности работы), тот и выиграл. Поэтому есть такая штука дедлайн, который реально надо соблюдать. То есть если ПМ говорит ведущему программисту: «Вася, у тебя на разработку вот этих модулей ровно месяц.», он это говорит не потому что хочет насолить Васе и его команде, или не потому что ни хрена не понимает в разработке. Он говорит так, потому что других сроков нет, и в 99% случаев делите тот срок который вам дал ПМ на 5 и получите тот срок, за который хотел работодатель чтобы вы всё сделали. А также не забывайте что у проекта есть не только программисты, есть концептологи, проектировщики, дизайнеры, верстальщики, админы, системные архитекторы, копирайтеры, спецы по юзабилити, рекламщики, менеджеры по продажам и туева куча других специальностей. ПМ должен знать и понимать работу каждого из них. То есть помимо работы Васи и его команды, ПМ должен понимать и знать работу ещё около 20 специальностей, включая определённые специализации этих специальностей. А ещё он должен знать свою работу в совершенстве. А ещё он в отличии от Васи должен обладать как гуманитарным, так и техническим складом ума. Он просит вас делать всё быстрее, потому что остальные люди не работают, а ждут когда вы сделаете определённую работу. Он рад бы чтобы проект был весь задокументирован, код был идеальным и вообще ни к чему нельзя было придраться, но это не художественная академия, чтобы выверять каждый штрих. Это бизнес, где большую роль играет скорость работы. В 99% случаев ПМ, ы это не менее, а порой даже и более творческие люди чем средний программист. В 60% случаев ПМ в IT раньше занимался программированием (в той или иной степени). Не надо обижаться на него за то что он вам ставит задачи и требует их исполнения в поставленный срок. Если вы не способны с ней справится — говорите сразу. Только не надо говорить ему о том, что вы не в состоянии сейчас определить сколько времени и сил понадобится на задачу и хватит ли вам их, если это действительно так — идите курит бамбук, вы не ведущий программист, и даже не программист, просто кодер. Я очень много работаю с хорошими прогерами и сам раньше занимался программированием — я сам заранее думаю сколько по срокам займёт подобная задача у моей команды и в 80% случаев всё сходится практически день в день. Ни разу не было чтобы я ошибся более чем на неделю (неделя в рамках 4 месяцев). Если вы хотите применять инновационные техники и методы, круто, но идите работать в исследовательский отдел какой-нибудь крупной компании (IBM, Microsoft, Google, etc.), но здесь, в жёстких условиях бизнеса, очень редко предоставляется возможность заняться инновациями.
В ообщем — не стоит считать ПМ, ов своими врагами, потому что они не понимают досконально суть вашей работы или ставят, как вам кажется, не те задачи с не теми сроками. Вы команда, братство, семья, да просто ахуенные ребята. Вы вместе выполняете одну задачу. По своему опыту скажу (я правда пить бросил уже давно) — сходите в бар всей командой, нажритесь до ужаса, а потом пойдите и начните выеживаться на банду байкеров. Вот тогда, после этого, вам будет что вспомнить и вы уже будете чувствовать себя единым целым. Когда ты знаешь, что вот Серёга парень хороший, но слабенький и не сможет уделать 5 байкеров одной левой и ты прикрываешь его, беря огонь на себя, или видя как ПМ разделывается с лидером байкеров, пытаетесь выбить тех, кто ему хочет помешать. Это реально весело:))) Работайте как единый механизм, создайте культ своей команды, считайте себя элитой, да всё что угодно делайте чтобы сплотится. Но никогда не устраивайте срач внутри команды. Если команда вас не устраивает, это не повод изменять команду, это повод уйти из этой команды.
Чем писать ТАКОЙ большой комментарий. Сделайте одно из двух
ИЛИ доработайте бы его до отдельного топика.
ИЛИ выжмите из него всю воду и ошибки.
ИЛИ доработайте бы его до отдельного топика.
ИЛИ выжмите из него всю воду и ошибки.
Если каждый, кто захочет жать развёрнутый ответ или возражение на какой-либо топик, будет его упаковывать в отдельный пост, хабр утонет в междоусобице.
Ошибки есть, не так уж правда их и много, оправдываться за них я не собираюсь, и говорить почему я их совершил тоже не буду — это только моё дело.
Вода которая здесь есть и есть суть работы, если вы не согласны с этим так и скажите. Это не техническая статья, чтобы говорить только факты. Да и технические статьи так уже давно не пишутся. А если вам лень читать, не надо меня учить писать так, как вам будет удобнее.
Ошибки есть, не так уж правда их и много, оправдываться за них я не собираюсь, и говорить почему я их совершил тоже не буду — это только моё дело.
Вода которая здесь есть и есть суть работы, если вы не согласны с этим так и скажите. Это не техническая статья, чтобы говорить только факты. Да и технические статьи так уже давно не пишутся. А если вам лень читать, не надо меня учить писать так, как вам будет удобнее.
Это не простая вода. Это Воды Селигера.
Только не надо говорить ему о том, что вы не в состоянии сейчас определить сколько времени и сил понадобится на задачу и хватит ли вам их, если это действительно так — идите курит бамбук, вы не ведущий программист, и даже не программист, просто кодер.
«Ты же профессионал!»
«Ты же профессионал!»
Здесь подразумевается, что если программист не может дать ориентировочные сроки по разработке какого-либо задания, то он некомпетентен как программист, он попросту кодер. То есть человек который пишет код и толком не знает о технологиях и о том как вообще всё работает.
Пример:
Один из ведущих программистов, с которым я когда то работал, смог без труда назвать мне примерные сроки выполнения работы по созданию собственной системы хелпдеска на сайте с использованием голосовой поддержки, при этом такие системы он никогда не разрабатывал, а с хелпдеском имел опыт работы только со стороны клиента. Но он постоянно был в курсе технологий и достаточно хорошо разбирался во всех отраслях разработки. Через два часа (обычно даётся 6-7 часов на анализ задачи и выставление сроков) он уже сказал кто ему нужен, что ему нужно и сколько на это необходимо времени, при этом время не отличалось от первоначально заявленного, а в итоге всё было разработано на два дня раньше (в общем было потрачено 9 дней). И это лишь один из случаев.
Есть ещё пример:
Меня наняли для разработки сайта, не особо сложного, но там необходимо было сделать возможность проигрывать видео. Ведущий программист, которого мне предоставили, был заявлен как высококлассный специалист в области веб-разработки со стажем в 7 лет. Когда я спросил у него сколько примерно времени потребуется для реализации задачи, услышал то, что часто слышал от обычных кодеров: «Я не знаю, ведь с технологией видео я никогда не работал и даже не представляю как она работает». Это был бы справедливый ответ для кодера, и быть может вполне сносный ответ для обычного программиста, но для ведущего программиста, который должен постоянно держать руку на пульсе технологий и уж точно должен знать как вообще работают такие популярные и повсеместные технологии как проигрывание видео на сайте, этот ответ неприемлем. Если программист не развивается и не изучает новые технологии — он кодер, либо узкоквалифицированный разработчик.
ПМ никогда не требует от рядового разработчика каких-то сроков, он требует их от ведущего программиста, который должен быть действительно профессионалом.
Пример:
Один из ведущих программистов, с которым я когда то работал, смог без труда назвать мне примерные сроки выполнения работы по созданию собственной системы хелпдеска на сайте с использованием голосовой поддержки, при этом такие системы он никогда не разрабатывал, а с хелпдеском имел опыт работы только со стороны клиента. Но он постоянно был в курсе технологий и достаточно хорошо разбирался во всех отраслях разработки. Через два часа (обычно даётся 6-7 часов на анализ задачи и выставление сроков) он уже сказал кто ему нужен, что ему нужно и сколько на это необходимо времени, при этом время не отличалось от первоначально заявленного, а в итоге всё было разработано на два дня раньше (в общем было потрачено 9 дней). И это лишь один из случаев.
Есть ещё пример:
Меня наняли для разработки сайта, не особо сложного, но там необходимо было сделать возможность проигрывать видео. Ведущий программист, которого мне предоставили, был заявлен как высококлассный специалист в области веб-разработки со стажем в 7 лет. Когда я спросил у него сколько примерно времени потребуется для реализации задачи, услышал то, что часто слышал от обычных кодеров: «Я не знаю, ведь с технологией видео я никогда не работал и даже не представляю как она работает». Это был бы справедливый ответ для кодера, и быть может вполне сносный ответ для обычного программиста, но для ведущего программиста, который должен постоянно держать руку на пульсе технологий и уж точно должен знать как вообще работают такие популярные и повсеместные технологии как проигрывание видео на сайте, этот ответ неприемлем. Если программист не развивается и не изучает новые технологии — он кодер, либо узкоквалифицированный разработчик.
ПМ никогда не требует от рядового разработчика каких-то сроков, он требует их от ведущего программиста, который должен быть действительно профессионалом.
Planning poker и вообще весь аджайл и всё что отличается от методологии «водопад» придумали некомпетентные кодеры.
Проблем то нет, просто надо набрать компетентных ведущих программистов, оценить сроки, а потом спроектировать, запрограммировать, протестировать и ввести в эксплуатацию с погрешностью в неделю.
Проблем то нет, просто надо набрать компетентных ведущих программистов, оценить сроки, а потом спроектировать, запрограммировать, протестировать и ввести в эксплуатацию с погрешностью в неделю.
Всё зависит от размера проекта и сложности задач. Аджаил и уж тем более покер я считаю вещью из разряда я придумал новое слово пурпунтуморам, то есть абсолютно бессмысленная вещь, абсолютно бессмысленные стандарты и ограничивание команды. Водопад это классика, и этот метод самый надёжный, но у него есть реальные недостатки. Итеративный метод также как и водопад имеет плюсы и минусы. Моё мнение, надо либо решать как работать в зависимости от поставленной задачи, либо с уже сформировавшейся командой придумать свою, идеальную для вас, схему работы. Агил и прочая мутотень это разряда книг как заработать миллион, основы GTD, основы тайм-менеджмента, помоги себе сам, сделай 12 шагов, в общем бред людей, которые 30% своей жизни общаются с психологами.
Так в этом и задача ПМ, тим лидера или HRM, к сожалению ПМ не всегда способен выбрать специалиста, а HRM не всегда понимает то что нужно команде. Поэтому если у вас есть хорошая команда, считайте что вам повезло.
Так в этом и задача ПМ, тим лидера или HRM, к сожалению ПМ не всегда способен выбрать специалиста, а HRM не всегда понимает то что нужно команде. Поэтому если у вас есть хорошая команда, считайте что вам повезло.
Идеализм…
Сроки — это смешно. Я перестал относиться к ним серьёзно.
Ну рассчитал ты время точно… Через пару недель выполнения задачи начальник «скорректирует» задание, увеличив сложность на порядок, а потом даст десяток очень срочных тасков, которые обязательно надо прямо сейчас выполнить. Потом он будет троллить на предмет несоблюдения/неумения рассчитывать сроки и годами отказываться повышать зарплату.
Ах да, если в первоначальную оценку сроков заложить всё вышеперечисленное, то на тебя посмотрят, как на дебила — «а почему так много? задача-то простая совсем. Не, нужно сделать в пять раз быстрее.»
Сроки — это смешно. Я перестал относиться к ним серьёзно.
Ну рассчитал ты время точно… Через пару недель выполнения задачи начальник «скорректирует» задание, увеличив сложность на порядок, а потом даст десяток очень срочных тасков, которые обязательно надо прямо сейчас выполнить. Потом он будет троллить на предмет несоблюдения/неумения рассчитывать сроки и годами отказываться повышать зарплату.
Ах да, если в первоначальную оценку сроков заложить всё вышеперечисленное, то на тебя посмотрят, как на дебила — «а почему так много? задача-то простая совсем. Не, нужно сделать в пять раз быстрее.»
Для этого существует ПМ или АМ (аккаунт-менеджер), который не даёт ничего корректировать и держит оборону перед клиентом. То есть в команде, где ПМ мужик с яйцами, подобные ситуации очень и очень редкое исключение, которое зачастую выясняется на этапе предварительных работ. Вы попросту не работали в нормальной команде с нормальным ПМ, ом. За всё время моего труда, я помню только два случая, когда мы скорректировали задание по ходу разработки, но (!) при этом я выбил дополнительное время и дополнительную оплату в первом случае, а во втором ведущий программист сам предусмотрел эти корректировки и когда я их стал вносить, он уже их сделал (это было только начало моей карьеры, где мне очень повезло с ведущим программистом). То есть найдите себе в ПМ, ы мужика с яйцами, который сможет отстоять команду перед клиентом.
Ну, вы говорите скорее не о ведущем разработчике, а руководителе отдела разработке/техдире — эти люди копают не в глубину, а в ширину, как и свойственно руководителям, читают статьи, тусят на хайлоадах, ритах, рифах, выписывают и кладут на рабочий стол журнальчики типа CEO ;-)
Но если его заставить покодить — он будет долго вспоминать детали.
Но если его заставить покодить — он будет долго вспоминать детали.
Быть может тут и есть какое-то разногласие в терминах, но главное что понятно о ком я говорю.
Но у меня был опыт сотрудничества с людьми развивающимися равномерно. То есть они были весьма большими профессионалами в управлении своей частью команды и при этом могли достаточно хорошо (подчёркиваю что не в совершенстве) программировать. Но главное что этот человек должен уметь, это собрать код воедино.
Ну вот даже если меня сейчас заставить покодить, я впринципе сразу смогу что-то написать:) Так что тут скорее всё зависит от человека, а не от его должности.
Но у меня был опыт сотрудничества с людьми развивающимися равномерно. То есть они были весьма большими профессионалами в управлении своей частью команды и при этом могли достаточно хорошо (подчёркиваю что не в совершенстве) программировать. Но главное что этот человек должен уметь, это собрать код воедино.
Ну вот даже если меня сейчас заставить покодить, я впринципе сразу смогу что-то написать:) Так что тут скорее всё зависит от человека, а не от его должности.
Поэтому есть такая штука дедлайн, который реально надо соблюдать. То есть если ПМ говорит ведущему программисту: «Вася, у тебя на разработку вот этих модулей ровно месяц.», он это говорит не потому что хочет насолить Васе и его команде, или не потому что ни хрена не понимает в разработке.
Я долго работал под руководством человека у которого было забавное отношение к дедлайнам. С одной стороны он постоянно пинал и очень торопил (в ушерб всему), с дургой стороны заваливал левыми заданиями («короткими и срочными»), проектами и просто поручениями в стиле подай/принеси/посчитай/объясни.
Я долго работал под руководством человека у которого было забавное отношение к дедлайнам. С одной стороны он постоянно пинал и очень торопил (в ушерб всему), с дургой стороны заваливал левыми заданиями («короткими и срочными»), проектами и просто поручениями в стиле подай/принеси/посчитай/объясни.
Если команда действительно сплоченная и действует как единое целое с PM — согласен, такую нужно беречь и если хочется поиграть, валить из нее.
Разработчик должен учиться оценивать свою работу. Чем его квалификация выше, тем точнее он это делает.
Но если сверху не руководитель, а начальник (разные понятия) — рекомендую бороться, чтобы пришел все таки лидер :-)
Разработчик должен учиться оценивать свою работу. Чем его квалификация выше, тем точнее он это делает.
Но если сверху не руководитель, а начальник (разные понятия) — рекомендую бороться, чтобы пришел все таки лидер :-)
Никто не заставляет работать на дебильного менеджера, а потом же высирать на него кирпичи.
Перефразируя князя Меншикова, всегда полезно напомнить оруще-увольняющему менеджеру, что после того, как он поувольняет всех грамотных программеров, «император останется один, без подданных». ))
После чего будет вынужден писать Г-код самостоятельно.
После чего будет вынужден писать Г-код самостоятельно.
Может быть немного не по теме, но я считаю что программировать должны все те кто связан с ИТ сферой, это как решать уравнения для тренировки мозгов, причем полезно как верстальщику так и менеджеру, так и программисту например на новом для него языке.
В общем, у любой задачи есть три важных момента, которыми можно управлять.
1. Сама формулировка задачи, постановка
2. Что требуется сделать в первую очередь
3. Минимальное допустимое качество.
Вот профессиональный программист, с которым легко и хорошо работать — это тот, кто думает о всех трех. Если не думает — должен думать менеджер.
Смысл в том, что задачи менеджера и программиста в «классической» ситуации противоположны — менеджеру нужно быстро и дешево, а программисту чаще важнее правильно и качественно.
Соответственно, нужно просто находить консенсус.
Но в целом. задачи менеджера важнее, и вот почему.
Во-первых, менеджер лучше знает то, что нужно. Во-вторых, он общается с людьми, шарит в предметной области, обладает видением функционала с кучи моментов. Программист же зачастую не утруждает себя погружением в детали области и связанности (и менеджер также не доносит до него важность этих моментов).
В-третьих, за счет быстрой разработки можно в единицу времени (неделя условно) проитерировать больше раз — и следовательно, приблизиться гораздо ближе к тому, что нужно, чем если делать долго. Потому что по опыту — нихера не дают бумаги и юзкейсы так, как дают реальные данные и реальные пользователи (или очень близкое к этому).
Поэтому в идеале управление разработкой функционала простое
— сначала переформулировать задачу, чтобы уменьшить сроки
— затем получить этапы по задаче. аыбрать самое важное вперед. уменьшить сроки.
— указать, что можно сделать говнокодом первые этапы (не делать таблицу в БД — просто массив в коде, к примеру, для простых списков, и т.д.)
— заверить, что будет дано время на рефакторинг
— показать, как доводить функционал до конца.
— проитерировать сначала быстро, чтобы получить МАКСИМАЛЬНО ТОЧНОЕ НУЖНОЕ в плане функционала, затем отрефакторить.
Баланс между скоростью и качеством.
1. Сама формулировка задачи, постановка
2. Что требуется сделать в первую очередь
3. Минимальное допустимое качество.
Вот профессиональный программист, с которым легко и хорошо работать — это тот, кто думает о всех трех. Если не думает — должен думать менеджер.
Смысл в том, что задачи менеджера и программиста в «классической» ситуации противоположны — менеджеру нужно быстро и дешево, а программисту чаще важнее правильно и качественно.
Соответственно, нужно просто находить консенсус.
Но в целом. задачи менеджера важнее, и вот почему.
Во-первых, менеджер лучше знает то, что нужно. Во-вторых, он общается с людьми, шарит в предметной области, обладает видением функционала с кучи моментов. Программист же зачастую не утруждает себя погружением в детали области и связанности (и менеджер также не доносит до него важность этих моментов).
В-третьих, за счет быстрой разработки можно в единицу времени (неделя условно) проитерировать больше раз — и следовательно, приблизиться гораздо ближе к тому, что нужно, чем если делать долго. Потому что по опыту — нихера не дают бумаги и юзкейсы так, как дают реальные данные и реальные пользователи (или очень близкое к этому).
Поэтому в идеале управление разработкой функционала простое
— сначала переформулировать задачу, чтобы уменьшить сроки
— затем получить этапы по задаче. аыбрать самое важное вперед. уменьшить сроки.
— указать, что можно сделать говнокодом первые этапы (не делать таблицу в БД — просто массив в коде, к примеру, для простых списков, и т.д.)
— заверить, что будет дано время на рефакторинг
— показать, как доводить функционал до конца.
— проитерировать сначала быстро, чтобы получить МАКСИМАЛЬНО ТОЧНОЕ НУЖНОЕ в плане функционала, затем отрефакторить.
Баланс между скоростью и качеством.
теперь допустим, менеджер идет на поводу у программиста, и дает делать долго и правильно.
смотрите, я юзер — я придумал таблицу.
заказал ее — делали ее мне две недели.
за эти две недели сто раз уже передумал, как именно мне нужно, и получил СТО ПРОЦЕНТОВ не то, что нужно. и еще и долго. сказал, как нужно — опять две недели. ппц, я зол — долго и не то, программист зол — все вечно переделывать.
теперь второй вариант.
говорю — таблицу. в тот же день показали. пощупал реальные данные, покрутил — говорю, вот сюда фильтр, сюда сортировку. окей, завтра еще раз показали. мое видение эволюционирует вместе с результатами, и я счастлив — делают быстро и результат налицо. окей, наконец все окей. даю время переписать нормально — и все, отрефакторят сразу в нужный функционал, потому что видение сформировано конечное функционала. программист счастлив — его хвалят, дали переписать нормально, все востребовано.
все гениальное — просто.
смотрите, я юзер — я придумал таблицу.
заказал ее — делали ее мне две недели.
за эти две недели сто раз уже передумал, как именно мне нужно, и получил СТО ПРОЦЕНТОВ не то, что нужно. и еще и долго. сказал, как нужно — опять две недели. ппц, я зол — долго и не то, программист зол — все вечно переделывать.
теперь второй вариант.
говорю — таблицу. в тот же день показали. пощупал реальные данные, покрутил — говорю, вот сюда фильтр, сюда сортировку. окей, завтра еще раз показали. мое видение эволюционирует вместе с результатами, и я счастлив — делают быстро и результат налицо. окей, наконец все окей. даю время переписать нормально — и все, отрефакторят сразу в нужный функционал, потому что видение сформировано конечное функционала. программист счастлив — его хвалят, дали переписать нормально, все востребовано.
все гениальное — просто.
Согласен. В этом подходе если проггер — профи и менеджер не мудак и сдерживает обещания по выделению времени на разбор говнокода — будет работать отлично.
отличный блог у Вас, кстати
www.1c-bitrix.ru/blog/alexander_serbul/
www.1c-bitrix.ru/blog/alexander_serbul/
Но — если менеджер «кинет» программиста и не даст время на рефакторинг, а еще хуже — передаст задачу своему коллеге с садистическими наклонностями то… а это часто бывает… программист затаит злобу на манагера и в следующий раз будет закладывать больше времени и врать. Таким образом должно быть доверие и уважение между тем и другим — и будет работать :-)
Sign up to leave a comment.
Принуждение к профанации — «рыночный» менеджмент