Comments 101
>> намного легче найти механика, который отлично разбирается в аэродинамике, чем пилота болида, под которого должна подстраиваться вся команда
аэродинамикой занимаются специалисты по аэродинамике, механик должен уметь разобрать и собрать машину из набора деталей. это не его дело, как там воздух бежит между частями машины )
аэродинамикой занимаются специалисты по аэродинамике, механик должен уметь разобрать и собрать машину из набора деталей. это не его дело, как там воздух бежит между частями машины )
да-да, это не его дело. только вот парадокс — у тех механиков, кто не считает что это «не его дело» зарплаты почему то выше…
если я программист с довольно немалым опытом в разных сферах web + game dev. И я Вам честно скажу мне насрать как работают дизайнеры вы хотите сказать я многое теряю?
Со статьёй во многом согласен, но честно говоря после прочтения какой-то осадок.
Со статьёй во многом согласен, но честно говоря после прочтения какой-то осадок.
Мне кажется у вас столько минусов, потому что нужно знать смежные области, интерфейсы так сказать. Мне кажется, что наплевать в вашей области можно например на то, какими средствами дизайнер пользуется и откуда черпает образцы, но как это он делает в абстрактном смысле понимать надо, ровно как работает верстальщик, и то, как устроена аппаратная часть сервера. Замечаю, как физически устроена аппаратная часть вам уже должно быть все равно.
Действительно так и есть. Когда-то в далекие студенческие годы я тоже так думал. И старался везде приткнуть… Это и 3DMax и Corel и электроника вдоль и поперек.
Но годы прошли я я точно знаю нужно быть специалистом в предельной (я не говорю ограниченной) области иначе рискуете быть поверхностным знатоком.
По поводу аппаратной части. Ввиду того, что моя прошлая область деятельность очень тесно связана, я конечно имею довольно немалый багаж в этой области. Но скажу Вам честно в 95% случаев это не нужно, чтобы быть хорошим специалистом.
А минуса — тут таких много. Минусуют, а сами молчат. Вы еще мне под дверь насрите. Поставил оценку чужого мнения — скажи своё.
Но годы прошли я я точно знаю нужно быть специалистом в предельной (я не говорю ограниченной) области иначе рискуете быть поверхностным знатоком.
По поводу аппаратной части. Ввиду того, что моя прошлая область деятельность очень тесно связана, я конечно имею довольно немалый багаж в этой области. Но скажу Вам честно в 95% случаев это не нужно, чтобы быть хорошим специалистом.
А минуса — тут таких много. Минусуют, а сами молчат. Вы еще мне под дверь насрите. Поставил оценку чужого мнения — скажи своё.
У Valve было описание людей специализацию людей который они очень ценят, Т-люди. Это люди с очень широким кругозором (верняя палочка буквы Т) и с глубоким опытом и знаниями в какой-то узкой специализации (вертикальная палочка в Т). Ваш подход «насрать» это значит что у вас только горизонтальная палочка в виде узкой специализации. По моему опыту ценность таких людей действительно немного ниже.
Скорее всего, switlle имеет в виду, что работа механика и ученого, разрабатывающего новые формы кузова, так же отличается, как и работа программиста и дизайнера. И никто не будет вам платить больше за то, что вы умеете подобрать красивое сочетание 5 цветов, зато это более чем вероятно, если вы «хорошо умеете» SQL или криптографию, например.
А какой осадок остался?
Если мы говорим о команде, то слово «насрать» к ней не применимо. каждый член команды должен понимать что делают остальные. И каждый должен знать зачем нужен каждый человек в команде и почему без него нельзя обойтись.
Тут вы правы. Но мне все равно не на них самих или то как они это делают. Я просто не хочу иметь эти знания. Уже хватит.
В достаточно больших командах это затруднительно. Не до абсолюта, конечно, но, например, я знаю что отдел продаж занимается продажами и этого мне достаточно — мои обязанности с их не соприкасаются никак, горизонтальные организационные связи не нужны ни мне, ни им. Продажник не подойдёт ко мне с просьбой вставить какую-то фичу, а я не подойду к нему с предложением устроить акцию в честь Дня программиста :). Это не предусмотрено workflow, подобные вещи идут чуть ли не через самую вершину должностной иерархии. И, да, я не знаю зачем нужны продажники, когда есть Гугл и Яндекс :) Утрирую, конечно, подозреваю, что без них мало кто будет искать точное название домена, но чем конкретно они занимаются мне не то, что плевать, а просто ортогонально.
Не болеете вы за свои проекты, сразу видно
Сейчас у меня и так свои проекты. И я Вам скажу мнение своё не поменял.
Лучше не болеть, чем когда тебя заставляют болеть. И лучше болеть, но соблюдать существующий воркфлоу, чем прыгать через голову начальства обоих. Я не пойму, если дизайнер будет мне советовать как именовать переменные шаблона, а он, наверное, не поймёт, если я буду советовать ему «чуть левее этот блок сдвинуть». Насчёт именования переменных мне лучше советоваться с верстальщиком/фронтендером, а насчёт расположения блоков дизайнеру с ним же. Верстальщик/фронтендер должен знать наши с дизайнером половые трудности, а мы его, но с дизайнером прямая горизонтальная связь не нужна. Имхо, такие связи зачастую не то что бесполезны, а просто вредны.
Вообще во время гонки вполне могут подкручивать аэродинамику машины, например, если пилот жалуется на недостаточную поворачиваемость болида. Не в формуле-1 конечно, но в других гонках вполне, хотя и в формуле-1 никто не мешает это делать, но на практике не видел.
Да что уж там говорить, как раз в формуле-1 используется DRS, которое на ходу может менять аэродинамику машины.
Да что уж там говорить, как раз в формуле-1 используется DRS, которое на ходу может менять аэродинамику машины.
Вообще-то, нужно разделять менеджера по продажам (общение с клиентов до проекта), менеджера по обслуживанию (общение с клиентом во время проекта) и менеджера проектов (общение с командой). И еще, хороший менеджер всегда более востребован на рынке труда, чем хороший разработчик.
Окей, приходит заказчик в компании — сделайте мне сайт такой-то, сколько это будет стоить и ещё вот у меня вопросы есть. Что скажет менеджер по продажам?
Правильно, ничего, потому что у неё образование 5 курсов ИнЯза и она в душе не знает, как устроены эти сайты.
Тут в дело и вступают технари, т.е. фактически иногда с первого, иногда со второго письма вся переписка — на технарях, которые умеют писать письма. А это обычно как раз такие менеджеры. А вы думали, откуда проекты берутся?
Правильно, ничего, потому что у неё образование 5 курсов ИнЯза и она в душе не знает, как устроены эти сайты.
Тут в дело и вступают технари, т.е. фактически иногда с первого, иногда со второго письма вся переписка — на технарях, которые умеют писать письма. А это обычно как раз такие менеджеры. А вы думали, откуда проекты берутся?
>Окей, приходит заказчик в компании — сделайте мне сайт такой-то, сколько это будет стоить и ещё вот у меня вопросы есть. Что скажет менеджер по продажам?
Он пойдет к менеджеру проектов, оценит себестоимость проекта, накинет стандартный процент наценки и ответит клиенту. Клиент получит внятный, обоснованный ответ. Так, например, у нас работают и весьма успешно ;)
Он пойдет к менеджеру проектов, оценит себестоимость проекта, накинет стандартный процент наценки и ответит клиенту. Клиент получит внятный, обоснованный ответ. Так, например, у нас работают и весьма успешно ;)
Так везде работают. Но 90% работы по пре-сейлу (заинтересовать заказчика, показать свой технический уровень, выбрать из технологий то, что нужно именно ему) делают технари.
Они дают информацию менеджеру по продажам, а он непосредственно продает. Т.е. он, грубо говоря, приходит к ПМу и спрашивает как это работает, а после уже разжевывает клиенту и делает продажу.
По крайней мере так должно быть…
Это более долгий путь. В 90% случаев (да и многие заказчики просят выйти на контакт) проще самому ПМ-у поговорить с заказчик, чем объяснять сейлу, который затем будет объяснять заказчику. Не понимаю, почему это не очевидно — зачем играть в испорченный телефон?
Потому что это не работа ПМа, он должен управлять проектами, а не с клиентами общаться.
Потому что продажа — это тоже работа, своя технология. Если продажа ещё не состоялась, сделка не подписана (а иначе что бы тут делал продажник?), то ПМ, особенно если он больше айтишник, чем манагер, может так наобщаться с клиентом, что тот просто свалит. А виноват будет — кто? — правильно, сейлз, потому что это его сфера ответственности была.
Если у вас техдиры и тимлиды с менеджерами проектов занимаются продажами, то у вас либо очень маленькая контора, либо просто неверно выстроенная работа.
Если у вас техдиры и тимлиды с менеджерами проектов занимаются продажами, то у вас либо очень маленькая контора, либо просто неверно выстроенная работа.
Такие у вас ПМ-ы, если не могут пообщаться с заказчиком. Всё равно ведь придётся позже — какая разница, с новым заказчиком или существующим.
Компания не маленькая, 250 человек, но ещё раз повторяю — в 90% случаев всё, что могут написать сейлы —
1) шаблонное письмо, какая у нас хорошая компания
2) сюсюкаться в скайпе и по переписке, говорить красивые фразы
3) немного управлять рейтами — где-то скинуть, где-то прибавить.
ДА, это делают они — я не спорю и не лезу туда. Но вот разговаривать с заказчиком на технические темы, делать оценки, отвечать на вопросы — это ПМ-ы и техлиды. Разве вы с этим не согласны?
Компания не маленькая, 250 человек, но ещё раз повторяю — в 90% случаев всё, что могут написать сейлы —
1) шаблонное письмо, какая у нас хорошая компания
2) сюсюкаться в скайпе и по переписке, говорить красивые фразы
3) немного управлять рейтами — где-то скинуть, где-то прибавить.
ДА, это делают они — я не спорю и не лезу туда. Но вот разговаривать с заказчиком на технические темы, делать оценки, отвечать на вопросы — это ПМ-ы и техлиды. Разве вы с этим не согласны?
Общение с клиентом на этапе продажи должно идти через продажника или при участии продажника. Полностью это отдавать нельзя.
Про ПМ пример не в кассу — общение с клиентом по поводу подписанного проекта и продажа — две разные вещи. Редко какой ПМ хотел бы быть продажником.
Про ПМ пример не в кассу — общение с клиентом по поводу подписанного проекта и продажа — две разные вещи. Редко какой ПМ хотел бы быть продажником.
по-моему мы спорим об одном и том же, просто упорно не хотим понимать друг друга.
Конечно, это работа не только ПМ-а — это работа ПМ-а + продажника. Но у ПМ-а она тоже выедает время
Конечно, это работа не только ПМ-а — это работа ПМ-а + продажника. Но у ПМ-а она тоже выедает время
Ну вот, за 4 сообщения вы таки пришли к мысли, что без сэйлзов никак нельзя. Хотя, в первом сообщении этой лесенки была такая нотка, мол всю работу делают технари, нафига нам эти неучи, ага…
Возможно я неоднозначно выразился, всю работу сейла (поиск, первое знакомство, инвойсы, ...), конечно же, делать не нужно. Нужно делать самое важное — хотя кто определит что важнее? Без нас обоих бы ничего не было.
Но и вы не попытались меня понять, а ухватились за эту нотку. Я совсем не о том писал, что сейлы не нужны.
Но и вы не попытались меня понять, а ухватились за эту нотку. Я совсем не о том писал, что сейлы не нужны.
Это применимо в крупных компаниях. Небольшие не могут позволить себе и сейлза, и аккаунта и ПМа
> хороший менеджер всегда более востребован на рынке труда, чем хороший разработчик.
но его сложнее найти
но его сложнее найти
Нужно, правильно. Но как написано в самом начале, статья не про большие команды. А в маленьких командах, менеджер часто и Team Lead и PM и Developer и Аналитик и кем только еще не является… Все зависит от проекта. На больших проектах и на больших командах роль менеджера менее смазанная и он выполняет в основном только те функции, которые подходят под описание профессии.
В маленьких командах так происходит потому, что нет выбора. И хочет или не хочет разработчик, а ему приходится выполнять не свои функции, потому что больше некому.
Или потому что не смог эту работу свалить на «смежника». Пример из веб-дева: есть дизайнер и есть сервер-сайд разработчик. Имхо, оба должны владеть вёрсткой в примерно одинаковой степени — знать основы html/css, чтобы разговаривать с верстальщиком на одном языке. Но угадайте кому из нас (я не дизайнер) чаще приходится верстать? Несмотря на то, что я и так совмещаю обязанности от своих непосредственных (писать код на PHP) до выбора конфигурации и поставщиков серверов и определения ценовой политики.
Вам уже больше никогда не написать самому ни красивый кастомный контрольчик
Ну и слава богу.
Вы уже, скорее всего, пресыщены, но иногде так хочется что-то сделать хорошо, и самому!
В этом и проблема сделать кастомный контрольчик хорошо.
Сразу огорюсь что я воспринимаю эту фразу в контексте вэба.
Сейчас только и занимаюсь что делаю кастомные контрольчики под дизайн и сделать их действительно качественно очень большая проблема — надо учеть работу с клавиатуры, фокусировки текста, выделение, события мыши, жестов на тачпаде, колёсико мышки, мультитач жесты, оптимизировать это под 3 платфоры, в каждой из которых свой механизм реализации и всё такое.
А что в итоге? Сделали красивенький контрол, который работает заметно медленнее нативного. Ради чего? Пользовательский опыт-то испорчен, хоть и карамелькой украшен.
Сразу огорюсь что я воспринимаю эту фразу в контексте вэба.
Сейчас только и занимаюсь что делаю кастомные контрольчики под дизайн и сделать их действительно качественно очень большая проблема — надо учеть работу с клавиатуры, фокусировки текста, выделение, события мыши, жестов на тачпаде, колёсико мышки, мультитач жесты, оптимизировать это под 3 платфоры, в каждой из которых свой механизм реализации и всё такое.
А что в итоге? Сделали красивенький контрол, который работает заметно медленнее нативного. Ради чего? Пользовательский опыт-то испорчен, хоть и карамелькой украшен.
А может, некоторые с детства мечтали спроектировать машину, не касаясь машинного масла и тормозной жидкости? :)
Я что-то слышал, что в некоторых компаниях практикуется следующая штука.
Ты когда становишься руководителем — читай менеджером, все равно должен выполнять проекты, процентов 30 своего времени. Мне кажется отличная практика.
Ты когда становишься руководителем — читай менеджером, все равно должен выполнять проекты, процентов 30 своего времени. Мне кажется отличная практика.
Ну а можно же уйти от сервисных компаний и пойти в продуктовые менеджеры в продуктовые компании? :)
У работы менеджера продукта есть один неоспоримый плюс — если у тебя амбиции достаточно больши и взгляды достаточно широки — ты можешь сделать на рынке что-то новое, революционное.
Можно еще в стартап, но все равно тебя все время будет смещать в продуктоводство…
У работы менеджера продукта есть один неоспоримый плюс — если у тебя амбиции достаточно больши и взгляды достаточно широки — ты можешь сделать на рынке что-то новое, революционное.
Можно еще в стартап, но все равно тебя все время будет смещать в продуктоводство…
видно что писал девелопер…
хороших специалистов всегда мало и без разницы какой профессии.
хороших специалистов всегда мало и без разницы какой профессии.
Тимлид — идеальное место. Уже есть кое-какая возможность принимать решения и руководить (а значит сделать больше клёвых велосипедов), но всё еще есть возможность творить, а не погрязнуть по уши в ворохе бумаг и телефонном трёпе.
Кстати, я тут немного спорю выше в комментариях по поводу содержания статьи, но сама мысль в заголовке ведь правильная! Если человеку интересно писать код, придумывать алгоритмы, решать программерские задачи, ему действительно не обязательно идти в менеджеры. Я знаю отличных программеров, которые уже не один десяток лет просто сидят, программят и чувствуют себя хорошо. Всегда нужно найти свое, а менеджмент — это далеко не для всех…
В конце концов кто-то же должен окучивать всех этих заказчиков и делать так, чтобы нам с ними общаться не приходилось?
Да, мысль отличная. «Если ты не хочешь быть менеджером — не иди в менеджеры».
Вы утрируете, но в целом мысль звучит именно так. Просто многие специалисты (особенно молодые) ещё не знают, что на самом деле не хотят идти в менеджеры. Т.е. они думают что хотят, но не знают что за этим последует. Для них и писал, т.к. сам таким когда-то был…
Помню в сочинении на английском в 9-м классе писал «I want not to become leading engineer-programmer. I want to become just simple engineer-programmer. Because I want not to manage men.» Может потому что в это время посещал «Школу юного менеджера» параллельно с курсами по dBase? :) В ШЮМ нравилась экономика, в dBase — программирование логики. Сейчас, блин, сижу проектирую структуру БД для манипулирования людьми :(
Вы меня конечно извините, но хороших IT Project Manager в РФ не готовят никак и нигде, люди подобной специальности по большей части знают всё (естественно поверхностно. без углублений, хотя бывают специализации) по технической части и абсолютно всё, что относится к гуманитарной (дизайн, юзабилити, психология, журналистика и т.д.), а ещё при этом являются менеджерами, то есть могут управлять людьми и что самое важное в IT — являются лидерами, которые двигают и мотивируют команду. И если вы хотите сказать что подобный специалист не найдёт себе работу (точнее найдёт её с меньшей долей вероятности чем девелопер), то вы очень глубоко заблуждаетесь. Эта профессия в которую попадают очень немногие и очень редко у них есть образование менеджера. Я уже много раз говорил, менеджмент в IT, а особенно проект-менеджмент, это совмещение несовместимого, по сути нахождение на грани точных и гуманитарных наук. Стив Джобс один из таких менеджеров.
Джобс как раз не из таких менеджеров. После того как он встретил Возняка, он не написал (образно говоря) ни строчки полезного кода. Во время презентации iAd (не так давно), было видно, что систему на практике он видит впервые (собственно, он так и сказал прямо на wwdc).
Его управленческая сила состояла в том, что ему казалось что он знает «как надо сделать», воплощая/тыря фичи, лежащие на поверхности (удобство, дизайн), и в том, что он мог грамотно подобрать под себя команду, которая будет исполнять его прихоти (кто с этим не справлялся — вылетал из компании). Он хорошо мотивировал работников. Я уверен, что его постоянные наставления сотрудникам «сделать лучше» (или, что называется push the boundaries — заставить сделать невозможное) исходили именно из не самого глубокого понимания технического вопроса. Проще говоря, Джобс просто не знал, что некоторые вещи невозможно сделать, и поэтому это у него его подчиненных так хорошо получалось.
Его управленческая сила состояла в том, что ему казалось что он знает «как надо сделать», воплощая/тыря фичи, лежащие на поверхности (удобство, дизайн), и в том, что он мог грамотно подобрать под себя команду, которая будет исполнять его прихоти (кто с этим не справлялся — вылетал из компании). Он хорошо мотивировал работников. Я уверен, что его постоянные наставления сотрудникам «сделать лучше» (или, что называется push the boundaries — заставить сделать невозможное) исходили именно из не самого глубокого понимания технического вопроса. Проще говоря, Джобс просто не знал, что некоторые вещи невозможно сделать, и поэтому это у него его подчиненных так хорошо получалось.
написано отлично. Особенно мне понравилось что вы отметили про забываемость всего, когда этим занимаешься. Назад сложно вернуться, в программирование, если вдруг захотелось
Я думаю статья стоило назвать: «Чего я боюсь, если я стану менеджером»
Не очень удачное название для статьи :) уже писал в комментариях выше — это для тех молодых людей, которым снится то, что они станут менеджерами. Я тоже когда-то таким был, поэтому и поделился своими мыслями.
Соль в том, что они не совсем понимают весь дёготь, который это принесёт, видя только ложку мёда. При почти равной зарплате SSE и менеджера на небольших и средних проектах нужно очень сильно подумать, прежде чем принимать оффер и челендж.
Соль в том, что они не совсем понимают весь дёготь, который это принесёт, видя только ложку мёда. При почти равной зарплате SSE и менеджера на небольших и средних проектах нужно очень сильно подумать, прежде чем принимать оффер и челендж.
Как сказал мне коллега, лид на большой команде — «ты чтобы отладить программу берёшь отладчик, я — MSProject».
Это очень интересно, но требует очень большого опыта именно сервиса, знать все чужие ошибки чтобы не прогореть на своём.
Мой первый опыт всё-таки прогорел (окупил процентов 20 инвестиций), правда я думаю скорее из-за маркетинга а не идеи и реализации, и в ближайшие несколько лет я, скорее всего, своими проектами заниматься не буду — чем больше делаешь сам, тем меньше понимаешь, как мало в таких тонких вещах ещё опыта. Это не кастомный контрольчик написать, да :)
Мой первый опыт всё-таки прогорел (окупил процентов 20 инвестиций), правда я думаю скорее из-за маркетинга а не идеи и реализации, и в ближайшие несколько лет я, скорее всего, своими проектами заниматься не буду — чем больше делаешь сам, тем меньше понимаешь, как мало в таких тонких вещах ещё опыта. Это не кастомный контрольчик написать, да :)
Каждому по потребностям. Если вы общительный человек, обладаете даром обаяния и/или убеждения — почему пропадать таланту? И такие менеждеры регулярно читают про технологии. Я стараюсь следить за моими менеждерами. Так вот они читают обзоры регулярно. И понимают какую технологию применить лучше чем обычный кодер, котрый год сидел на одном проекте ничего не видел кроме своего стека технологий. Они не знаю какие хитрости в том или ином проекте, но общее понимание у них выше имхо.
Мне видимо повезло как-то, являясь ПМ, я попутно еще и продажник, переродившийся во все это из разработчика. Тут скорее вопрос не в том, что специфика работы такая, а в том как ты к ней относишься. Мы например делаем сайты, и я как манагер, стараюсь прежде всего помогать людям, при чем как своим (команде), так и клиенту. И знаете, это тоже кайф. Кайф в том, что выдержал сроки, не раздул бюджет, решил поставленную клиентом задачу, закрыл проект. Наверное каждый из этих пунктов, достоин небольшого такого томика, но я не об этом. Главное, любить, то что ты делаешь, и относиться к своей работе ответственно и ставить целью — помощь людям, а не загребания бабла и развод клиента на много денег. Вопрос отношения к работе — можно так же ненавидеть кодинг например. Как говориться, jedem das Seine.
Никогда не думал об этимологии «болгарки». Из текста узнал, что это от болгарской пилы. =)
Коллеги.
Очень долго сам думал над этим вопросом.
Видно, что пост написал разработчик.
Сразу скажу с чем не согласен
Хороший менеджер так же находит работу на следующий день после увольнения, и то не находит, а выбирает из предложенных.
Так как, ко мне очень часто обращаются за просьбой найти людей, включая менеджеров, то я могу сказать, что, например, сейчас я могу устроить человека, как минимум в 5 компаний ТОР рынка веб разработок и не только.
Как раз из-за проблемы кадрового голода, мы и открыли образовательный проект РИК
Теперь, пару слов о классическом треугольнике Sales-Account-Manager. В нашей сфере, я считаю, что не бывает и не может быть такого разделения, чтобы Sales только продавал, Account только общался с клиентом, а Manager только вел проект внутри команды. Потому что, цель сейлза это продать, соответственно, он готов давать скидки, обещать нереализуемый космос, а что потом с проектов будет ему все равно, в итоге получаются либо убыточные проекты, либо суды, либо какашки, а не хорошие продукты.
Sales+Account, Manager – схема, которая работает лучше, но как раз в компаниях крупных, у которых уже есть пул клиентом и где есть Аккаунт-директор, который сразу ведет пул клиентов и у него в подчинении менеджеры, которые ведут клиентов. Аккаунту остается пушить новые продажи внутри клиента, дружить с ним. А менеджеры ведут проекты
Sales, Account+Manager – схема, которая что-то среднее, опять возникает проблема сейлза, который продает все подряд. Так же есть проблема с клиентом, т.к. он не понимает, почему это вдруг, он верит сейлзу и покупает услугу и сразу ему представляют другого человека. И этот человек, например, не нравится клиенту и сразу возникают проблемы.
Sales+account+manager – наверно, это возможно только в маленьких компаниях, в крупных, тупо не хватит времени.
НО, хочу отметить, что человек, должен быть универсалом. Объясняю.
Если account не будет иметь навыков сейлза или менеджера, то он не сможет хорошо продать проект. Т.к. он должен разбираться во всем процессе и уметь продавать.
Менеджер, который не умеет общаться с клиентом и тоже пушить новые услуги, который не умеет работать с требованиями и не умеет управлять требованиями, так же не сможет провести проект так, чтобы клиент был доволен.
И под конец, хочу еще написать психолоческую стороны данного вопроса.
Менеджеры и разработчики принципиально различные по складу ума.
Разработчики любят процесс, готовы делать, переделывать еще лучше, потом еще раз переделывать.
Менеджерам же, главное результат и сроки.
И именно по-этому, разработчик редко становится хорошим менеджером, который умеет держать сроки, и абсолютно так же менеджер не станет разработчиком, он не любит процесс.
Я люблю именно менеджент, только менеджер может погружаться в бизнес клиента, а ведь каждый новый клиент, это новый бизнес и новые знания, в котором ты начинаешь разбираться. Это очень большое саморазвитие. Очень часто, хорошие менеджеры из агентств идут на сторону клиента бизнес консультантом, т.к. за годы работы видели очень много других безнесов изнутри и разбираются во всем этом деле.
Спасибо за внимание.
Очень долго сам думал над этим вопросом.
Видно, что пост написал разработчик.
Сразу скажу с чем не согласен
Хороший менеджер так же находит работу на следующий день после увольнения, и то не находит, а выбирает из предложенных.
Так как, ко мне очень часто обращаются за просьбой найти людей, включая менеджеров, то я могу сказать, что, например, сейчас я могу устроить человека, как минимум в 5 компаний ТОР рынка веб разработок и не только.
Как раз из-за проблемы кадрового голода, мы и открыли образовательный проект РИК
Теперь, пару слов о классическом треугольнике Sales-Account-Manager. В нашей сфере, я считаю, что не бывает и не может быть такого разделения, чтобы Sales только продавал, Account только общался с клиентом, а Manager только вел проект внутри команды. Потому что, цель сейлза это продать, соответственно, он готов давать скидки, обещать нереализуемый космос, а что потом с проектов будет ему все равно, в итоге получаются либо убыточные проекты, либо суды, либо какашки, а не хорошие продукты.
Sales+Account, Manager – схема, которая работает лучше, но как раз в компаниях крупных, у которых уже есть пул клиентом и где есть Аккаунт-директор, который сразу ведет пул клиентов и у него в подчинении менеджеры, которые ведут клиентов. Аккаунту остается пушить новые продажи внутри клиента, дружить с ним. А менеджеры ведут проекты
Sales, Account+Manager – схема, которая что-то среднее, опять возникает проблема сейлза, который продает все подряд. Так же есть проблема с клиентом, т.к. он не понимает, почему это вдруг, он верит сейлзу и покупает услугу и сразу ему представляют другого человека. И этот человек, например, не нравится клиенту и сразу возникают проблемы.
Sales+account+manager – наверно, это возможно только в маленьких компаниях, в крупных, тупо не хватит времени.
НО, хочу отметить, что человек, должен быть универсалом. Объясняю.
Если account не будет иметь навыков сейлза или менеджера, то он не сможет хорошо продать проект. Т.к. он должен разбираться во всем процессе и уметь продавать.
Менеджер, который не умеет общаться с клиентом и тоже пушить новые услуги, который не умеет работать с требованиями и не умеет управлять требованиями, так же не сможет провести проект так, чтобы клиент был доволен.
И под конец, хочу еще написать психолоческую стороны данного вопроса.
Менеджеры и разработчики принципиально различные по складу ума.
Разработчики любят процесс, готовы делать, переделывать еще лучше, потом еще раз переделывать.
Менеджерам же, главное результат и сроки.
И именно по-этому, разработчик редко становится хорошим менеджером, который умеет держать сроки, и абсолютно так же менеджер не станет разработчиком, он не любит процесс.
Я люблю именно менеджент, только менеджер может погружаться в бизнес клиента, а ведь каждый новый клиент, это новый бизнес и новые знания, в котором ты начинаешь разбираться. Это очень большое саморазвитие. Очень часто, хорошие менеджеры из агентств идут на сторону клиента бизнес консультантом, т.к. за годы работы видели очень много других безнесов изнутри и разбираются во всем этом деле.
Спасибо за внимание.
Мне будучи разработчиком приходилось погружаться в бизнес клиента, хотя я скорее совмещал функции аналитика и разработчика. Разве не бизнес-аналитик ака постановщик задач должен погружаться в самые тонкости бизнеса клиента, выясняя все мелочи вплоть до того на каких основаниях бутылка может покинуть склад или что будет если тот же кладовщик ногу сломает?
К сожалению, это не бизнес задачи, а техническая стороная бизнеса.
Настоящий менеджер должен понимать в:
психологии (для выстраивания отношения с командой)
маркетинге (для предложения правильного решения задачи клиента)
технике (чтобы общаться правильно с командой)
Менеджер должен уметь правильно презентоваться и презентовать.
я этот список могу продолжать долго :)
Но, иногда я завидую разработчиком, например, они могут сидеть на Бали и оттуда работать.
Когда зимой, один из программистов, который жил на Бали сказал «Тач, подожди пожалуйста, пойду кружок на катере вокруг острова сделаю, а то мозг перестал работать», а я сижу зимой в Москве, готов был убить :)
Прям хочет написать кавер на это статью, с темой «Почему вам не стоит идти в разработчики» :)
Настоящий менеджер должен понимать в:
психологии (для выстраивания отношения с командой)
маркетинге (для предложения правильного решения задачи клиента)
технике (чтобы общаться правильно с командой)
Менеджер должен уметь правильно презентоваться и презентовать.
я этот список могу продолжать долго :)
Но, иногда я завидую разработчиком, например, они могут сидеть на Бали и оттуда работать.
Когда зимой, один из программистов, который жил на Бали сказал «Тач, подожди пожалуйста, пойду кружок на катере вокруг острова сделаю, а то мозг перестал работать», а я сижу зимой в Москве, готов был убить :)
Прям хочет написать кавер на это статью, с темой «Почему вам не стоит идти в разработчики» :)
На самом деле, я уже 3 года занимаюсь почти всё время чистым менеджментом (до этого 3 года работал разработчиком), но я продолжаю считать себя и тем, и другим.
Т.к. пост писался в основном для разработчиков, и его целью было сказать, что большинству разработчиков по тем или иным причинам не нужно стремиться в менеджеры, я и писал от лица разработчика.
Я всё ещё хорошо понимаю психологию разработчика, как ОН смотрит на повседневные вещи, поэтому наверное вы не первый человек в этом треде, который так подумал :) Но это для меня комплимент — в айти менеджер, который ушёл в графики Jira-ы и MS Project без проникновения в детали и понимания сути разработки — потерянные и ненужный человек. Да, я горжусь тем, что я программист!
Есть одно такое заблуждение среди менеджеров — они все считают программистов несколько однобокими, повёрнутыми на технологиях и сосредоточенными на чём-то одном. Это так в 50% случаев, среди не очень одарённых программистов и джуниоров, но никак не верно в отношении остальных 50% — особенно тех, у кого есть за плечами опыт фриланса.
Настоящий инженер в смысле, в котором его употребляют на Западе — это и есть почти менеджер. Это далеко не кодер, это человек с отличным образованием и широким взглядом на вещи. Например, сериал побег — там Скофилд всё отлично организовывает и продумывает.
В общем, настоящие SSE и настоящие менеджеры — это по сути люди с одинаковыми способностями, просто одним чуть-чуть больше нравится одно, а другим — другое. Не нужно их так категорично разделять.
Т.к. пост писался в основном для разработчиков, и его целью было сказать, что большинству разработчиков по тем или иным причинам не нужно стремиться в менеджеры, я и писал от лица разработчика.
Я всё ещё хорошо понимаю психологию разработчика, как ОН смотрит на повседневные вещи, поэтому наверное вы не первый человек в этом треде, который так подумал :) Но это для меня комплимент — в айти менеджер, который ушёл в графики Jira-ы и MS Project без проникновения в детали и понимания сути разработки — потерянные и ненужный человек. Да, я горжусь тем, что я программист!
Есть одно такое заблуждение среди менеджеров — они все считают программистов несколько однобокими, повёрнутыми на технологиях и сосредоточенными на чём-то одном. Это так в 50% случаев, среди не очень одарённых программистов и джуниоров, но никак не верно в отношении остальных 50% — особенно тех, у кого есть за плечами опыт фриланса.
Настоящий инженер в смысле, в котором его употребляют на Западе — это и есть почти менеджер. Это далеко не кодер, это человек с отличным образованием и широким взглядом на вещи. Например, сериал побег — там Скофилд всё отлично организовывает и продумывает.
В общем, настоящие SSE и настоящие менеджеры — это по сути люди с одинаковыми способностями, просто одним чуть-чуть больше нравится одно, а другим — другое. Не нужно их так категорично разделять.
Заметьте, я не писал именно про SSE (читай технической директор), т.к. по-сути SSE, как и Арт директор, относятся к топ менеджменту, который должны по большей мере управлять процессом разработки внутри своих.
Человек у которого был опыт фриланса и более того, он не закончился плачевно, это и есть будущий SSE, обычный разработчик, который не умеет общаться с людьми (клиентами, менеджерами и т.д.) никогда не станет ведущим, какие бы у него не были таланты по разработке.
Человек у которого был опыт фриланса и более того, он не закончился плачевно, это и есть будущий SSE, обычный разработчик, который не умеет общаться с людьми (клиентами, менеджерами и т.д.) никогда не станет ведущим, какие бы у него не были таланты по разработке.
со всем согласен, только наверное всё же не топ-менеджменту, а просто менеджменту среднего звена.
Ну тогда кого же вы считаете топ менеджером в сферен дизайна или разработки?
Обычно подразумевают птиц повыше, например википедия приводит такой список занимаемых должностей:
Т.е. их зона ответственности выше, чем у SSE. Каждый технический директор, скорее всего, SSE, но никак не наоборот.
- генеральный директор;
- исполнительный директор;
- технический директор;
- операционный директор;
- финансовый директор.
Т.е. их зона ответственности выше, чем у SSE. Каждый технический директор, скорее всего, SSE, но никак не наоборот.
Вкус к менеджменту приходит со временем. После 6 лет работы как ПМ, я даже не представляю как можно сидеть и заниматься одной задачей, скажем, неделю. Я привык «воротить горы» задач и решать множество проблем чужими руками. И да, есть обратная сторона медали…
Женское мнение. Будучи в «вечном декрете» мне проще быть девелопером, чем менеджером, хотя уходила в тот самый декрет с позиции менеджера. Нет возможности работать в офисе и кем-то руководить. Так что работа на дому с небольшими веб-проектами пока единственный для меня вариант поддерживать свои професиональные навыки.
Мне понравилось, когда я работал дизом в компании наш Начальник говорил:
если ты любишь решать задачи — будешь хорошим специалистом, если любишь сваливать задачи на других — из тебя вырастит отличный менеджер))
Самое главное да, это отличие в мышлении. Менеджер мыслит целями, и ему не так важен процесс. А разработчик кайфует от процесса и ему нет особого дела до сроков. С возрастом уровень ответственности возрастает, а значит уже отвечаешь за конкретные дела (цели и сроки), меняется мышление (становится целевым) и становятся разработчики Тим-лидами, а потом руко(языком)водителями и в процесс не вмешиваются!
если ты любишь решать задачи — будешь хорошим специалистом, если любишь сваливать задачи на других — из тебя вырастит отличный менеджер))
Самое главное да, это отличие в мышлении. Менеджер мыслит целями, и ему не так важен процесс. А разработчик кайфует от процесса и ему нет особого дела до сроков. С возрастом уровень ответственности возрастает, а значит уже отвечаешь за конкретные дела (цели и сроки), меняется мышление (становится целевым) и становятся разработчики Тим-лидами, а потом руко(языком)водителями и в процесс не вмешиваются!
Sign up to leave a comment.
Почему вам не стоит идти в менеджеры