Комментарии 110
Не совсем понял заголовок вашей статьи.
Что вы хотели этим сказать?
Что вы хотели этим сказать?
Сдаётся мне, что это отсылка к книге «как пасти котов».
Может автор хотел сказать, что программисты — это скот?
Вопрос к автору — как вы определите какой специалист обычный, какой высококласный а какой плохой?
Проблема в том что ты не сказал для кого специалист должен быть классным…
Например для конторы оутсорсинга дело обстоит так.
Вариант 1
Час работы senier 50$ ему отдают 25$.
Он выполнил работу за 10 часов. профит конторы 250$
Вариант 2
Час работы middle 30$ ему отдают 15$.
Три мидла выполнили работу за 20 часов и принесли конторе 900$
Ну и какой специалист высококлассный для руководства конторы?
Например для конторы оутсорсинга дело обстоит так.
Вариант 1
Час работы senier 50$ ему отдают 25$.
Он выполнил работу за 10 часов. профит конторы 250$
Вариант 2
Час работы middle 30$ ему отдают 15$.
Три мидла выполнили работу за 20 часов и принесли конторе 900$
Ну и какой специалист высококлассный для руководства конторы?
Есть задача. Есть две оценки: 10 часов, 1 человек (цена — $500) и 20 часов, 3 человека (цена — $1800).
Риторический вопрос: что выберет заказчик?
Риторический вопрос: что выберет заказчик?
Риторический вопрос: что выберет заказчик?
Риторический ответ: 10% как бонус скорее всего склонит его к третьему варианту — с джуниорами.
Простите вы заказчику продаете сотрудника или все же результат работы? Если стоимость работ для заказчика 1800, то не трудно посчитать что senior получив свои 250 баксов заработал для фирмы 1550. Плюс к этому в некоторых случаях заказчик готов платить больше за более быстрое выполнение работы, но не наоборот. Иначе выгоднее всего было нанимать людей которые вообще не умеют программировать время выполнения работы этими сотрудниками стремиться к бесконечности… PROFIT.
Смотреть нужно не на текущую рентабельность, а на рентабельность проекта (с учетом багфиксов, запуска, поддержки). А так да, для фриланс-заказов на 10 часов выгоднее всего наиболее дешевый из подходящих, как уже указали ниже.
Для этого есть правило первое :)
По сути, формальных критериев для этого нет (и я считаю, не нужно их искать, иначе получите не хороших, а соответствующих). Но по работе и по отношению в команде это видно, и этого достаточно.
Вашими бы устами. Обычно бывает всё наоборот.
Бывают способные, а бывают обычные. Способный разработчик эффективнее обычного раз в десять.
Зарплата бывает хорошая, а бывает обычная. За хорошую зарплату я работаю эффективнее раз в десять чем за обычную. Так какой же я разработчик?
опытный?
где-то с 80-х годов было подмечено, что производительность специалистов уровня от среднего и выше не зависит от зарплаты. Отсюда все эти социальные пакеты, игровые комнаты в офисах, 20% на личные проекты и прочая неденежная мотивация.
Так что вы скорее всего разработчик ниже среднего или зарабатываете очень мало относительно в среднем по рынку.
Так что вы скорее всего разработчик ниже среднего или зарабатываете очень мало относительно в среднем по рынку.
Нет, у меня средний уровень. Под словом «обычная» я имел в виду именно среднюю по рынку, если брать мой регион. Если брать среднюю по всей планете, то да, просто мизер.
Не знаю что там подметили в 80-х, но по моим наблюдениям, мантру «деньги не мотиватор», продолжают повторять только в конторах с зарплатами ниже среднего. Когда компания не может замотивировать сотрудника материально, она начинает искать способы подмены ценностей. Все эти игровые комнаты, тимбилдинги и и прочие печеньки на кухне. А если сотрудник не мотивируется мишурой и продолжает просить больше денег, он у них сразу плохой специалист с низкой мотивацией от которого нужно избавляться. Ну ясен пень, все хотят получить сеньора за три бакса. Только получают они в итоге специалиста, который 50% рабочего времени тратит на развитие себя для поиска другой работы, а не на то, чтобы сделать больше для своей компании.
Не знаю что там подметили в 80-х, но по моим наблюдениям, мантру «деньги не мотиватор», продолжают повторять только в конторах с зарплатами ниже среднего. Когда компания не может замотивировать сотрудника материально, она начинает искать способы подмены ценностей. Все эти игровые комнаты, тимбилдинги и и прочие печеньки на кухне. А если сотрудник не мотивируется мишурой и продолжает просить больше денег, он у них сразу плохой специалист с низкой мотивацией от которого нужно избавляться. Ну ясен пень, все хотят получить сеньора за три бакса. Только получают они в итоге специалиста, который 50% рабочего времени тратит на развитие себя для поиска другой работы, а не на то, чтобы сделать больше для своей компании.
Если разработчик сидит на совещании — он не работает.
в рамочку и на стену. самое главное правило, которое должны усвоить любители совещаний.
Вот с этим утверждением не согласен — совещания тоже бывают разные, например у нас они как правило неформальные и технические, на них обсуждается как прийти к консенсусу между пожеланиями менеджеров и возможностями разработчиков, выбираются и обсуждаются технические решения. На совещание на котором обсуждаются рыночные нюансы или ещё что-то не относящееся к разработке — программистов и не позовут)
Вот именно, совещания бывают разные, присутствие специалиста на некоторых из них в интересах самого-же специалиста, например, когда решается вопрос о развитии системы над которой специалист работает. Если он не принимает в нём участие, то решения принимают менеджеры разной степени эффективности исходя из собственного понимания, опыта и тараканов.
НЛО прилетело и опубликовало эту надпись здесь
Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного.
Правило № 9 очень интересное — оно означает (гауссово распределение), что нужно систематически искать, выявлять и увольнять почти всех средне-нормальных спецов.
Если в программировании это как то (и в специальных случаях — типа сильного роста зарплаты для нового сотрудника) и работает, то вот в других сферах — вряд ли.
А так нужные "звёзды" уволятся сами; им даже не нужно искать более доходное место для работы — к ним занимают очередь с предложениями.
Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного. Хотя, на мой взгляд, испытательный срок в три месяца вполне достаточен для того, чтобы понять, что за специалист к Вам устраивается.
1. Большая текучка в рамках 3 месяцев в итоге приведет к тому, что на работу будут приходить разве что вообще ни какие специалисты, потому как хорошие, а там более отличные специалисты, такие конторы просто проходят мимо. И поверьте как правило в комьюнити люди знают что на самом деле происходит в тех или иных компаниях. Земля как говорится слухами полнится.
2. Хорошие специалисты как правило амбициозны и ищут пути для развития и повышения, какой смысл тратить время и силы на вашу шарагу если через год другой тебя просто попросят со словами «вы нам не подходите мы нашли лучше».
Есть ещё один замечательный момент — чтобы программисту, в отличии от грузчика, включиться в работу компании и начать приносить пользу — нужно несколько месяцев, а то и пол года потратить на изучение продукта, разрабатываемого в компании, в течении которого как его польза, так и польза от других разработчиков его отдела будет меньше, чем была до перехода его в компанию. Будет тратится время на изучение и структуры проекта, и на консультации с более опытными товарищами, изучение части используемых инструментов и т.д… В результате может получиться, что разработчика уволят к тому времени, когда он только-только начал окупать вложенные в него средства.
Да вы что опухли что ли там все. Какие такие несколько месяцев. Разработчик может приносить пользу уже через две недели, а через несколько месяцев может делать всё что надо.
Но может и не приносить вообще никогда, а за эту зарплату ещё и немножечко вредить.
Но может и не приносить вообще никогда, а за эту зарплату ещё и немножечко вредить.
Бывший начальник, принимая меня на работу, очень хотел клятв, что я никуда не сбегу: «А то ж знаем мы вас, пока тут осмотритесь, да обучитесь, да освоитесь, через год только пользу приносить начнёте, а уже возьмёте и уйдёте в другое место!» Ладно, приняли, задачу поставили, спрашивает, когда будет готово? Говорю, ну, прямо щас не готов ответить, надо же осмотреться и освоиться, вы же сами сказали, что на это уйдёт год. «Шшшштоаа?!!?! Какой ещё год, мы вам не можем такого позволить! Максимум у вас есть неделя на это!» Так я узнал, что поговорка «без году неделя» имеет совершенно конкретное, практическое применение.
Речь в тексте статьи идёт о сложных проектах — 2 недели это если он собирается под условной пользой считать: подметание пола в офисе и тому подобные вещи.
Germanets не совсем так. В большинстве случаев человек начинает приносить пользу делать годные коммиты через неделю-месяц от начала действия трудового договора. Наблюдал такое много раз на собственном и чужом примере в проекта сложностью от 1-го пид-регулятора(с набором коммуникаций по уровням) до 50к java кода, обрабатывающего(хранение, анализ) фискальные сообщения.
Хотя да, в «хрестоматии» написано, увеличение кол-ва разработчиков сокращает:
— скорость команды
— ускорение команды
в главе про «смоляные ямы», кажется.
Хотя да, в «хрестоматии» написано, увеличение кол-ва разработчиков сокращает:
— скорость команды
— ускорение команды
в главе про «смоляные ямы», кажется.
я думаю автор немного топорно выразился, и имел в виду что за период испытательного срока отчётливо видно приносит работник пользу или он особо ничего не делает или создаёт видимость бурной деятельности, к тому же он может отнимать достаточно много времени у других работников допуская грубые ошибки, которые эти самые работники после него разбирают и объясняют ему что так делать не надо, нет я ни в коем случае не говорю что все люди идеальны, но если человек дилетант и далеко не соответствует квалификации, то такого программиста не специалист не вычислить никогда, а то и подружится с ним потому что он постоянно мило беседует с ним и рассказывает много интересных технических «штук»
так же есть вариант «не сошлись характером», — тоесть руководителю просто не удалось нормально замотивировать человека и направить его энергию в нужное русло
так же есть вариант «не сошлись характером», — тоесть руководителю просто не удалось нормально замотивировать человека и направить его энергию в нужное русло
если человек дилетант и далеко не соответствует квалификации, то такого программиста не специалист не вычислить никогда, а то и подружится с ним потому что он постоянно мило беседует с ним и рассказывает много интересных технических «штук»
Особо печально, когда первый — генеральный директор, второй — технический. А тот, с кем не сошлись характерами, он какие-то «странные штуки» говорил и вообще в «облаках витает»
Дочитав, я обнаружил, что статья прекрасна уже тем, что в ней нет ни слова про KPI и Agile :)
Это безусловно идеальные правила для идеального мира. Но в условиях бизнеса не выжить, без нарушений правил и оптимизации первых трех.
Ну просто куча замечаний…
«На переключение между разнородными задачами необходимо до 2-х дней,… Нормальный человек при переключении между задачами теряет до недели времени»
Вы уж определитесь, 2 дня или неделя, и откуда вообще такие цифры, из чьей головы?
«Если разработчик сидит на совещании — он не работает»
Если ведущий разработчик проводит совещание с коллегами на тему того как и куда им дальше двигаться в разработке, то это (ВНЕЗАПНО) и совещание и работа! Так же ведущий разработчик может и должен привлекаться на этапе ТЗ, для правильной оценки уровня технических задач, степени их реализуемости и сложности. И да, это все тоже делается на совещаниях, и да, в этот момент этот специалист работает.
«Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.»
Так считают все посредственные руководители. «Это же элементарно, что там делать? Раздал задачи и только галочки в расписании проставляй.»
«Если хорошего программиста труднее найти, чем среднего руководителя, то и получать он должен большую зарплату, чем руководитель нижнего звена.»
То руководитель средний, то нижний… Опять сумбур какой-то. Зарплата специалисту зависит от возможностей компании и той пользы, которую приносит данный специалист для этой компании. А так да, я бы тоже хотел чтобы мне только за регалии деньги платили.
«Есть специалисты высококлассные, есть специалисты обычные. И если плохого спеца уволить можно, состряпав комиссию, которая выявит его несоответствие занимаемой должности, то обычного специалиста уволить невозможно, если он не совершает грубых дисциплинарных проступков. Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного.»
Ура, мы добрались до сути, оказывается, есть только ВЫСОКОКЛАССНЫЕ и ОБЫЧНЫЕ. Причем «обычные»=«плохие».
Очень хочется спросить у автора: «Вы когда-нибудь сами-то руководили командой, где одни „звезды“?»
В реальной жизни, на проект требуются не только высококлассные специалисты, но и вполне себе обычные, т.к. «рутину» высококлассные специалисты делают плохо, и это их демотивирует. А еще в команде есть условные «джуниоры», которые замотивированы на решение простых задач, чтобы на них научиться делать более сложные.
И вообще, вопрос формирования команды, куда более сложен, чем «давайте наймем высококлассных спецов за овермного денег и они нам все напишут».
«На переключение между разнородными задачами необходимо до 2-х дней,… Нормальный человек при переключении между задачами теряет до недели времени»
Вы уж определитесь, 2 дня или неделя, и откуда вообще такие цифры, из чьей головы?
«Если разработчик сидит на совещании — он не работает»
Если ведущий разработчик проводит совещание с коллегами на тему того как и куда им дальше двигаться в разработке, то это (ВНЕЗАПНО) и совещание и работа! Так же ведущий разработчик может и должен привлекаться на этапе ТЗ, для правильной оценки уровня технических задач, степени их реализуемости и сложности. И да, это все тоже делается на совещаниях, и да, в этот момент этот специалист работает.
«Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.»
Так считают все посредственные руководители. «Это же элементарно, что там делать? Раздал задачи и только галочки в расписании проставляй.»
«Если хорошего программиста труднее найти, чем среднего руководителя, то и получать он должен большую зарплату, чем руководитель нижнего звена.»
То руководитель средний, то нижний… Опять сумбур какой-то. Зарплата специалисту зависит от возможностей компании и той пользы, которую приносит данный специалист для этой компании. А так да, я бы тоже хотел чтобы мне только за регалии деньги платили.
«Есть специалисты высококлассные, есть специалисты обычные. И если плохого спеца уволить можно, состряпав комиссию, которая выявит его несоответствие занимаемой должности, то обычного специалиста уволить невозможно, если он не совершает грубых дисциплинарных проступков. Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного.»
Ура, мы добрались до сути, оказывается, есть только ВЫСОКОКЛАССНЫЕ и ОБЫЧНЫЕ. Причем «обычные»=«плохие».
Очень хочется спросить у автора: «Вы когда-нибудь сами-то руководили командой, где одни „звезды“?»
В реальной жизни, на проект требуются не только высококлассные специалисты, но и вполне себе обычные, т.к. «рутину» высококлассные специалисты делают плохо, и это их демотивирует. А еще в команде есть условные «джуниоры», которые замотивированы на решение простых задач, чтобы на них научиться делать более сложные.
И вообще, вопрос формирования команды, куда более сложен, чем «давайте наймем высококлассных спецов за овермного денег и они нам все напишут».
Вы ведь "начальник"?
Нет
Очень странно тогда, что в таких простых вещах запутались. "средний руководитель нижнего звена" — что тут может вызвать трудности? Или переключение нормального человека в неделю, а крутого в 2 дня. Недоумеваю...
Кто это «средний руководитель нижнего звена»? Можно пример?
Переключение контекста у человека происходит за 15 минут. Это эмпирическая величина. Если требуется неделя, или даже два дня, то… это диагноз, увы.
А уж мыслить категориями «нормальный», «крутой», на техническом ресурсе… это как направление в море пальцем показывать. Плюс у каждого свои понятия «крутой» и «нормальный».
Переключение контекста у человека происходит за 15 минут. Это эмпирическая величина. Если требуется неделя, или даже два дня, то… это диагноз, увы.
А уж мыслить категориями «нормальный», «крутой», на техническом ресурсе… это как направление в море пальцем показывать. Плюс у каждого свои понятия «крутой» и «нормальный».
Кто это «средний руководитель нижнего звена»? Можно пример?
ПМ? "Средний" относится к способностям, "нижнего звена" — к должности :)
А уж мыслить категориями «нормальный», «крутой», на техническом ресурсе…
А у вас есть технические, точные и метрологически выверенные шкалы квалификаций и общепринятые методики их оценки? Поделитесь, пожалуйста. Думаю, всем будет интересно!
это как направление в море пальцем показывать.
Не всякие величины могут быть градуированы в абсолютных значениях.
Плюс у каждого свои понятия «крутой» и «нормальный».
Но, даже те, которые не могут быть градуированы, вполне могут быть ранжированы и пригодны для оценки, анализа и прочей работы с ними. В рамках заданной выборки "крутой" ранжируется выше "нормального". Да, это действительно почти всё, что об этом можно сказать. И это нормально. Самые основы предмета, который во времена оны преподавался под названием "системный анализ", а сейчас, в связи девальвацией этого термина мененджерами, называется "системной инженерией". Его перестали преподавать? Куда катится образование… :(
«ПМ? „Средний“ относится к способностям, „нижнего звена“ — к должности :)»
ПМ в компаниях может быть значительно выше «нижнего» звена, в зависимости от проекта, который он реализует.
«А у вас есть технические, точные и метрологически выверенные шкалы квалификаций и общепринятые методики их оценки? Поделитесь, пожалуйста. Думаю, всем будет интересно!»
Нет, у меня нет, но и автор свои критерии определения «нормальности» и «крутости» не привел. У меня, например, «нормальным» считается специалист, который справляется со своими обязанностями, «хорошим» — который делает немного сверх и может в смежные области, а «крутой» — это тот кто эксперт в своей области, плюс понимает потребности бизнеса в целом и в создаваемом продукте, в частности. Опять-таки, какие критерии у автора — тайна.
ПМ в компаниях может быть значительно выше «нижнего» звена, в зависимости от проекта, который он реализует.
«А у вас есть технические, точные и метрологически выверенные шкалы квалификаций и общепринятые методики их оценки? Поделитесь, пожалуйста. Думаю, всем будет интересно!»
Нет, у меня нет, но и автор свои критерии определения «нормальности» и «крутости» не привел. У меня, например, «нормальным» считается специалист, который справляется со своими обязанностями, «хорошим» — который делает немного сверх и может в смежные области, а «крутой» — это тот кто эксперт в своей области, плюс понимает потребности бизнеса в целом и в создаваемом продукте, в частности. Опять-таки, какие критерии у автора — тайна.
ПМ в компаниях может быть значительно выше «нижнего» звена, в зависимости от проекта, который он реализует.
Может быть, может не быть. Вы ж пример просили. В примере — нижнее :).
Нет, у меня нет, но и автор свои критерии определения «нормальности» и «крутости» не привел.
Ну, вы дальше-то не прочли, что ли? Нет критерия, есть только компаратор. "Крутой" — выше "нормального" и всё. Этого достаточно в данном случае.
Опять-таки, какие критерии у автора — тайна.
Ну, в рамках описанного, эта информация не даст ничего нового. Зачем её знать?
"«Крутой» — выше «нормального» и всё. Этого достаточно в данном случае."
Этого не достаточно, т.к. непонятно о чем автор говорит, по каким критериям связывать упомянутых автором разработчиков, с разработчиками, которых представляют себе читатели.
С тем же успехом, можно было, крутых и нормальных заменить на «плюк» и «пляк», и сказать, что «пляк» круче, чем «плюк». В теории понятно, но с какими объектами связывать в реальности — не ясно.
Этого не достаточно, т.к. непонятно о чем автор говорит, по каким критериям связывать упомянутых автором разработчиков, с разработчиками, которых представляют себе читатели.
С тем же успехом, можно было, крутых и нормальных заменить на «плюк» и «пляк», и сказать, что «пляк» круче, чем «плюк». В теории понятно, но с какими объектами связывать в реальности — не ясно.
Этого не достаточно, т.к. непонятно о чем автор говорит, по каким критериям связывать упомянутых автором разработчиков, с разработчиками, которых представляют себе читатели.
Вы сами сказали, что у вас нет критериев абсолютной оценки, но при этом требуете её у других. Занятный случай.
Я думаю, что вы придуриваетесь, но могу, в принципе, и рассказать как, если вы и в самом деле тупите.
Слово "нормальный" в русском языке имеет коннотацию "близкий к среднему уровню", слово "крутой" — коннотацию "близкий к верхнему уровню. Дальше совсем просто. Читатель ранжирует программистов своего круга и тех, кто у верхнего края сопоставляет с крутыми, а тех, кто в серединке — с нормальными. Абсолютные величины здесь абсолютно не важны. Мне странно, что приходится объяснять настолько простые вещи.
С тем же успехом, можно было, крутых и нормальных заменить на «плюк» и «пляк», и сказать, что «пляк» круче, чем «плюк».
Да, разумеется. Если идти ещё дальше, то там в глубине обнаружится вообще формальная арифметика с набором правил вывода, но данная задача не требует такого уровня абстракции.
В теории понятно, но с какими объектами связывать в реальности — не ясно.
Я описал интерпретацию. Как у всякой формальной системы, она не единственная ;).
Где я требовал абсолютную оценку? Я лишь хотел чтобы автор описал свое понимание.
Ваш дальнейший… текст… я даже комментировать не хочу. Если для вас понятие среднего это величина, которая одинаково воспринимается всеми остальными, то вы живете в каком-то очень изолированном мире.
Повторю специально для вас, с разжевыванием, постарайтесь читать текст медленно. Автор описал случай, который может восприниматься как «наймите команду студентов, вместо школьников, потому что студенты круче», а может как «наймите команду профессионалов с опытом больше 20 лет, вместо среднечков с опытом 10 лет». Чувствуете разницу? Переложите на свое восприятие и попробуйте понять что же на самом деле имел в виду автор, говоря что «крутые круче средненьких».
Ваш дальнейший… текст… я даже комментировать не хочу. Если для вас понятие среднего это величина, которая одинаково воспринимается всеми остальными, то вы живете в каком-то очень изолированном мире.
Повторю специально для вас, с разжевыванием, постарайтесь читать текст медленно. Автор описал случай, который может восприниматься как «наймите команду студентов, вместо школьников, потому что студенты круче», а может как «наймите команду профессионалов с опытом больше 20 лет, вместо среднечков с опытом 10 лет». Чувствуете разницу? Переложите на свое восприятие и попробуйте понять что же на самом деле имел в виду автор, говоря что «крутые круче средненьких».
Где я требовал абсолютную оценку? Я лишь хотел чтобы автор описал свое понимание.
Ваш дальнейший… текст… я даже комментировать не хочу. Если для вас понятие среднего это величина, которая одинаково воспринимается всеми остальными
Ну, вы даёте. Сначала отнекиваетесь от абсолютной оценки, а потом про неё же опять шарманку заводите. "одинаково воспринимается" — это и есть абсолютная оценка. И, нет, это только для вас так. Для меня ровно наоборот. Среднее в моей выборке не равно среднему в вашей. А я вам три раза пытался объяснить, что абсолютная оценка в данной задаче не требуется. Давайте ещё раз — большая стрелка на 12, маленькая на 6… Система оценок выстраивается отдельно для каждого отдельно взятого множества. Между разными множествами нет параллелей, они не нужны. Да, при этом на множестве работников условного гугла их "нормальные" будут скорее всего где-то за горизонтом крутизны на множестве работников средней уеб-студии. Но в этом нет проблемы. Каждый читатель строит свои множества и свои распределения. Он работает со своими множествами, он их знает, он их понимает. Чужие ему совершенно бесполезны.
Слушайте, ну, правда, где вы учились, что не можете представить работу с абстрактными множествами над которыми только операция сравнения задана?
Автор описал случай, который может восприниматься как «наймите команду студентов, вместо школьников, потому что студенты круче»,
Да, именно так. Если у вас в распоряжении только школьники и студенты, или возможность нанять только школьников и студентов, то какой смысл вам советовать нанять Линуса Торвальдса? Вы просто не поймёте в чём тут смысл. Или скажете — блин, не могу нанять Торвальдса, значит всё пропало. Но нахрена вам Торвальдс, если для решения вашей проблемы вам достаточно поменять школьнака на студента?
Переложите на свое восприятие и попробуйте понять что же на самом деле имел в виду автор, говоря что «крутые круче средненьких».
Можно обьяснить что два плюс два будет четыре, считая окурки, а можно, считая космические корабли. И второй вариант ни чем не круче первого. Результат-то одинаков.
Отличный коммент. Командой я не руководил. Статья родилась как ответ на виденное в жизни… На попытки некоторых товарищей собрать команду лоботрясов, которые должны сделать сложный проект. При этом системного архитектора там не было.
Все Ваши замечания очень годные. За исключением пары — про совещания. Имеется в виду не совещание с коллегами, а совещание по административной части. Болтовня в чайной часто перерастает в техническое совещание. Против технических совещаний я ничего не имею.
У Вас, судя по всему, более позитивный опыт в работе. У меня не так.
Все Ваши замечания очень годные. За исключением пары — про совещания. Имеется в виду не совещание с коллегами, а совещание по административной части. Болтовня в чайной часто перерастает в техническое совещание. Против технических совещаний я ничего не имею.
У Вас, судя по всему, более позитивный опыт в работе. У меня не так.
НЛО прилетело и опубликовало эту надпись здесь
Просто вопрос — что стоит за изложенными принципами:
— опыт работы разработчиком?
— опыт работы руководителем?
— опыт работы разработчиком и руководителем в разные последовательные периоды времени?
— опыт работы разработчиком?
— опыт работы руководителем?
— опыт работы разработчиком и руководителем в разные последовательные периоды времени?
Есть прокол в правиле №8:
В остальном хорошо.
Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.Руководитель — это прежде всего ответственность. Супер программист отвечает за свою работу, а руководитель отвечает за работу нескольких супер программистов. За ответственность нужно платить. Вот как раз найти опытного программиста/конструктора легче, чем ответственного опытного руководителя.
В остальном хорошо.
Возьмем обычный средний город. Не долину, не Москву или не город-миллионник в РФ. А, скажем, город в 500к населения.
Предположим, половина этого населения работает, в то время как вторая — это пенсионеры, дети, студенты и люди, живущие на не свои или на нетрудовые доходы. 250к.
Предположим, что у половины работающего населения есть начальники. 125к
Предположим, что один руководитель нижнего звена обеспечивает роботоспособность 20 подчиненных. 6 250 руководителей.
Предположим, что половина из них бездари, горлопаны и люди, любящие издеваться над другими людьми. Вторая половина — плюс-минус адекватные люди (т.н. «нормальные»). 3 125 руководителей.
Внимание вопрос: как много опытных и более-менее нормальных программистов по популярному языку, возьмем 1С (упаси боже), вы найдете в городе с населением в 500к?
P.S.: опытный руководитель умеет делать крайним не себя, а кого-то другого. У опытного руководителя скорее всего были в практике и были провалы. Скажет Вася-разработчик виноват, его и уволят (ну или премии лишат, если это все-таки нужный сотрудник).
Предположим, половина этого населения работает, в то время как вторая — это пенсионеры, дети, студенты и люди, живущие на не свои или на нетрудовые доходы. 250к.
Предположим, что у половины работающего населения есть начальники. 125к
Предположим, что один руководитель нижнего звена обеспечивает роботоспособность 20 подчиненных. 6 250 руководителей.
Предположим, что половина из них бездари, горлопаны и люди, любящие издеваться над другими людьми. Вторая половина — плюс-минус адекватные люди (т.н. «нормальные»). 3 125 руководителей.
Внимание вопрос: как много опытных и более-менее нормальных программистов по популярному языку, возьмем 1С (упаси боже), вы найдете в городе с населением в 500к?
P.S.: опытный руководитель умеет делать крайним не себя, а кого-то другого. У опытного руководителя скорее всего были в практике и были провалы. Скажет Вася-разработчик виноват, его и уволят (ну или премии лишат, если это все-таки нужный сотрудник).
Вы упорно не хотите замечать в моей реплике слово «ответственный».
Я утверждаю, что ответственный руководитель априори должен получать больше ответственного подчинённого программиста. За лидерские качества, хранение секретов, ответственность за людей, человек-лидер должен получать больше любого гения программиста.
P.S. Я живу в Кирове ( 500k — как раз ваш пример) и к нам в очередь стоят программисты 1С, чтобы обслужить нашу деятельность.
Я утверждаю, что ответственный руководитель априори должен получать больше ответственного подчинённого программиста. За лидерские качества, хранение секретов, ответственность за людей, человек-лидер должен получать больше любого гения программиста.
P.S. Я живу в Кирове ( 500k — как раз ваш пример) и к нам в очередь стоят программисты 1С, чтобы обслужить нашу деятельность.
Гениев априори меньше, чем людей, которые в состоянии проконтролировать нормальные управленческие и хозяйственные процессы (приход-уход с работы, отпуска-больничные, постановку-выполнение задач, написание документации, закупку материалов и ОС). Грубо говоря, для ответственного управления подходит каждый двадцатый, ладно, пусть каждый сотый человек, а гении встречаются чуточку реже. Ответственность за людей в производстве кода? Это какая-то смешная ответственность, расскажите про неё тем, кто ходит под уголовной статьей, выпуская людей в цех или в шахту. Секреты хранить должны все уровни, толку от того, что начальник молчит как красный партизан, а подчиненные болтают на каждом углу, как солдаты в питейном заведении?)
К тому же, речь идет про руководителей нижнего звена, понятно, что от руководителей уровня предприятия требуются уже немного другие навыки и таланты.
Так что хороший руководитель нижнего уровня, конечно, ценен, но не ценнее гения.
К тому же, речь идет про руководителей нижнего звена, понятно, что от руководителей уровня предприятия требуются уже немного другие навыки и таланты.
Так что хороший руководитель нижнего уровня, конечно, ценен, но не ценнее гения.
В этом и вся беда нашего подхода к делу. До тех пор, пока мы считаем, что руководитель это тот, кто контролирует:
Но вы правы, гении встречаются редко и обычно им руководители не нужны.
Я выпускаю людей в цех.
приход-уход с работы, отпуска-больничные, постановку-выполнение задач, написание документации, закупку материалов и ОСмы будем путаться в определениях. Ведь вы говорите здесь не об управленцах, но о контролирующих органах. Всё это должно быть автоматизировано и регламентировано. Если очень кратко, управленец это тот, кто заряжает и качает команду. Это и есть самая большая ответственность (вместе с уголовной),
Но вы правы, гении встречаются редко и обычно им руководители не нужны.
Я выпускаю людей в цех.
Если у вас не стартап а-ля SpaceX, зачем вам «заряжать» и «качать»? Но ладно, я согласен, руководителям верхнего звена всё же надо обладать и харизмой и виденьем даже в условно типовом бизнесе.
Но зачем это уметь делать начальнику абсолютно каждого уровня, каждого подразделения: «заряжать» и «качать»? Вы представляете себе начальника АХО, который с утра заряжает и раскачивает персонал? Или цехового мастера? Или главного бухгалтера?.. Нет, я конечно понимаю, что бывают сложные периоды (например, внедрения нового инструментария, перехода на другой техпроцесс, авралы, срочные заказы), когда нужно подчинных мотивировать работать производительнее, чем обычно, потому что из-за изменных (отличных от нормальных) условий выросла нагрузка, но в целом?
…
Если вы несете реальную ответственность, то я согласен, что вы будете получать больше даже очень талантливого рабочего, потому что если ему сбодуна однажды отфигачит пальцы, а вы его выпустили с «выхлопом» в цех — попадёте именно вы.
Но зачем это уметь делать начальнику абсолютно каждого уровня, каждого подразделения: «заряжать» и «качать»? Вы представляете себе начальника АХО, который с утра заряжает и раскачивает персонал? Или цехового мастера? Или главного бухгалтера?.. Нет, я конечно понимаю, что бывают сложные периоды (например, внедрения нового инструментария, перехода на другой техпроцесс, авралы, срочные заказы), когда нужно подчинных мотивировать работать производительнее, чем обычно, потому что из-за изменных (отличных от нормальных) условий выросла нагрузка, но в целом?
…
Если вы несете реальную ответственность, то я согласен, что вы будете получать больше даже очень талантливого рабочего, потому что если ему сбодуна однажды отфигачит пальцы, а вы его выпустили с «выхлопом» в цех — попадёте именно вы.
Если у вас не стартап а-ля SpaceX, зачем вам «заряжать» и «качать»?
А в чём принципиальная разница между всеми проектами мира если смотреть с позиции персонала? Ответственность врача из международной клиники, такая же как и у сельского лекаря.
Но зачем это уметь делать начальнику абсолютно каждого уровняА как вы хотели? Как ваша харизма и виденье дойдёт до самого низа, если на одной из горизонтали она остановиться на безразличном ко всему мастере цеха. В чём тогда будет ваша ценность?
Есть разница. Смотрите, предположим вы стартап и берете деньги у инвесторов или у людей, по факту, за еще несуществующий товар. Вы продаете им идею: ракеты будут летать по нескольку раз и это будет дешево. В вашу идею вкладываются. Есть ULA, есть Роскосмос, которые смеются над вами и работают по старинке. У них полувековая традиция, у них оборудование, специалисты. У вас — лишь идея и, возможно, некоторые наработки. И вы должны за предоплаченные деньги, желательно в срок, её реализовать. Реализовали — вы молодец, вы сдвинули парадигму. Не реализовали — следующий визионер столкнется с равнодушием инвесторов или частных людей. Они скажут «мы уже слышали это, и это плохо кончилось» и не дадут денег.
У международной клиники есть бренд. У её клиентов есть выбор. У сельского лекаря нет конкурентов, независимо от его компетентности.
Ваша харизма должна зарядить изначально пофигистичного мастера, чтобы и он чуточку внимательнее относился к своим обязанностям. Или, если у вас совсем небольшое предприятие, вы сами зарядить все предприятие, если на то есть отдельный повод. Тут же как — люди смотрят на самый верх предприятия и в общем случае подмечают, что да как.
А если мастер цеха не заряжается от своего визионера, то его нужно вовремя сменить, на более устремленного человека.
Я к чему клоню — визионер наверху это хорошо, но в уже отлаженных коллективах и производствах, это как кофе. Выпей чашечку — почувствуешь прилив сил. Подсядешь на кофеин — кружки эспрессо с перерывом в 2 часа будут давать бодрости на 30 минут, и хорошо если вообще давать. А пить надо. Пьешь и пьешь. А останавливаешься — вообще всё плохо.
У международной клиники есть бренд. У её клиентов есть выбор. У сельского лекаря нет конкурентов, независимо от его компетентности.
Ваша харизма должна зарядить изначально пофигистичного мастера, чтобы и он чуточку внимательнее относился к своим обязанностям. Или, если у вас совсем небольшое предприятие, вы сами зарядить все предприятие, если на то есть отдельный повод. Тут же как — люди смотрят на самый верх предприятия и в общем случае подмечают, что да как.
А если мастер цеха не заряжается от своего визионера, то его нужно вовремя сменить, на более устремленного человека.
Я к чему клоню — визионер наверху это хорошо, но в уже отлаженных коллективах и производствах, это как кофе. Выпей чашечку — почувствуешь прилив сил. Подсядешь на кофеин — кружки эспрессо с перерывом в 2 часа будут давать бодрости на 30 минут, и хорошо если вообще давать. А пить надо. Пьешь и пьешь. А останавливаешься — вообще всё плохо.
Вы продаете им идею: ракеты будут летать по нескольку раз и это будет дешево. В вашу идею вкладываются. Есть ULA, есть Роскосмос, которые смеются над вами и работают по старинкеЯ не вижу здесь ничего такого, что идёт в разрез с моими убеждениями. Просто нет в РосКосмосе русских Илонов. Нет у нас таких людей. Нет заряженности на успех, открытия. Читали последние новости про YotaPhone? Мы всегда пытаемся догонять. И смеёмся над теми, кто хочет покорить Марс.
У международной клиники есть бренд. У её клиентов есть выбор. У сельского лекаря нет конкурентов, независимо от его компетентности.Жизнь (как противопоставление смерти) тракториста из Простоквашино и жизнь бизнесмена из Лондона равноценны для вселенной.
Ваша харизма должна зарядить изначально пофигистичного мастера,Я об этом же. Но если между нами есть ещё начальник цеха, то я буду действовать через него. А он уже на мастера. Именно так действует правильный настрой на работу.
А останавливаешься — вообще всё плохоА вот нельзя останавливаться (я про работу)! Сам кофе не пью, поэтому не могу провести параллель.
Будущее за неравнодушными, за людьми-зарядками!
А как вы хотели? Как ваша харизма и виденье дойдёт до самого низа, если на одной из горизонтали она остановиться на безразличном ко всему мастере цеха. В чём тогда будет ваша ценность?
Кажется я понял. Бывают начальники, которые думают что если он не будет дергать подчиненных и спрашивать отчеты на каждую минуту рабочего времени, то подчиненные будут лазать по деревьям и спать.
Бывают начальники...
Видимо бывают. У каждого свой стиль управления и свой стиль подчинения. На каждого самодура находятся те, кто спит на деревьях.
Я только не понял, как это относится к моей мысли о создании сплочённой команды.
Приведите пример, как вы «заряжаете» команду, как сплачиваете.
Думаю что это на уровне дерганий, совещаний, отчетов и натужных попыток убедить работать овертайм
Думаю что это на уровне дерганий, совещаний, отчетов и натужных попыток убедить работать овертайм
Приведите пример, как вы «заряжаете» команду, как сплачиваете.
Способов очень много. Все они очень просты и описаны в книгах. Из моего опыта, самые действенные:
1. Собственное и искреннее чувство в успехе при реализации любого проекта. Это неминуемо передаётся всем остальным
2. Подача собственного примера. Например, я никогда не опаздываю на работу. И когда утром все на местах, когда все ориентируются на тебя — это безумно здорово. Или когда мои коллеги не могут решить задачу, садишься с ними и как в школе говоришь — «Ну что, давайте вместе раскрутим этот клубок».
3. Объявление нобелевской премии (куда без денег?). За реализацию любого проекта всегда объявляю премию. За решение задачи (у нас в основном технические), которую я сам не могу решить или решили без моей помощи — нобелевская (очень большая) премия.
4. Постоянная, скрытая, ненавязчивая, словесная пропаганда командного духа. Бежишь по предприятию и делаешь точные инъекции боевого духа сотрудникам, каждому индивидуально подбирая свою дозу.
Думаю что это на уровне дерганий, совещаний,
У нас один раз, по пятницам.
натужных попыток убедить работать овертайм
Вообще это запрещаю. Лень и временнЫе рамки — двигатель прогресса. В таких условиях на свет появляются очень хорошие технические решения.
У нас производственное предприятие. Не знаю как это можно всё сопоставить с IT компаниями. Но мне кажется, что природа человека во всех компаниях одинакова.
1С-ники это не совсем те программисты, о которых идёт речь.
Хороший инженер часто ответственнее начальника. Т.к. он может влиять на ситуацию и болеет за то дело, которое делает. Руководитель тоже болеет, но сделать ничего не может.
Хороший инженер часто ответственнее начальника. Т.к. он может влиять на ситуацию и болеет за то дело, которое делает. Руководитель тоже болеет, но сделать ничего не может.
Первое правило — хренотень. Руководитель должен быть лидером, понимать устройство рынка, интересы бизнеса, потребности потребителей. Должен быть коммуникабельным, экстравертом, немного психологом, чтобы объединять вокруг себя умных людей и вести их в нужном направлении. Должен постоянно коммуницировать с «гуманитарными» сотрудниками (отделом продаж, отделом маркетинга и т.д.)
И вы хотите, чтоб он ещё и код писал? Да щас, блин.
Второе правило тоже хренотень. Даже лень объяснять почему.
И вы хотите, чтоб он ещё и код писал? Да щас, блин.
Второе правило тоже хренотень. Даже лень объяснять почему.
А почему нет? Он не должен писать код — он должен понимать, как пишется код. Как ни странно, у меня уже на второй работе технически подкованное руководство, вплоть до директора который тоже понимает достаточно много в используемых инструментах.
Вчера "руководил" общественной баней, сегодня "руководит" командой разработчиков? Да, в совке так и было. Ну, и вы помните к чему это привело...
Ну как бы примеры есть.
Вчера расстреливал врагов народа, сегодня испытал атомную бомбу <:o)
Иметь опыт разработки для руководителя разработчика желательно, но по моему не обязательно.
Главное, чтобы понимал, что делают программисты.
А этого можно добиться не имея практических навыков.
Вчера расстреливал врагов народа, сегодня испытал атомную бомбу <:o)
Иметь опыт разработки для руководителя разработчика желательно, но по моему не обязательно.
Главное, чтобы понимал, что делают программисты.
А этого можно добиться не имея практических навыков.
Расскажите, как?
Я уверен, что без практики можно добиться иллюзии понимания, но не самого понимания.
Я уверен, что без практики можно добиться иллюзии понимания, но не самого понимания.
Пример атомный проект СССР и США.
Где возглавляли/управляли те у кого не всегда был опыт научных разработок и создание атомной промышленности :-)
Тут дело все в делегировании и кадровой политике.
Хороший руководитель найдет тех, кто может решать поставленные задачи и обеспечит им условия для работы.
Где возглавляли/управляли те у кого не всегда был опыт научных разработок и создание атомной промышленности :-)
Тут дело все в делегировании и кадровой политике.
Хороший руководитель найдет тех, кто может решать поставленные задачи и обеспечит им условия для работы.
Они соблюдали Правила :)
Обратите внимание, цитата из первого правила: «Я знал немало руководителей, которые полностью перекладывали технические вопросы на подчинённых, восхищались людьми, умеющими делать технику, и задавали только два вопроса: «Когда будет готово?» и «Что необходимо для работы?». Это отличный стиль руководства для неспециалиста. Подводный камень здесь только один — кадровая политика. Ошибка в кадровой политике может вылиться в срыв проекта и потерю должности. Если с кадрами повезло, то остаётся лишь обеспечить их работу. О том, как её обеспечивать — читайте следующие правила.»
Автор, видимо, отлично разбирается в разработке, но слабо разбирается в руководителях (как минимум хороших и плохих). Аргументирую вывод: распространенная ошибка в том, что руководитель тот, кто следит/контролирует подчиненных. Функция контроля самая очевидная и видимо поэтому воспринимается главной. В то время как это лишь небольшая часть и возникает она как следствие. Вспомню пример Генри Форда, который проверил руководителей на "хороших vs плохих" посредством их отсутствия. Смог руководитель грамотно все организовать и работа шла хорошо и слаженно — руководитель хороший. Если же все дела валились у сотрудников из рук, значит, без своего руководителя они ни на что не годятся и виноват в этом, конечно, только сам руководитель.
Это очень хорошая статья.
Спасибо!
Спасибо!
Насчет шестого правила не согласен. Я бы его разделил на две части. Люди (и специалисты) бывают разные. У нас в отделе есть разработчик, который стоит как минимум двух других, а то и трёх. Быстро работает, быстро учится, не боится сложных задач. Умеет в алгоритмы.
Но количество ошибок велико. Как правило, довольно простых. И возникают они, как раз, из-за фантастической скорости разработки. А затереть чужой обновленный код из своей старой ветки — это вообще едва ли не через день. Да, кто-то скажет, система контроля версий и т.д., но учитывая реальность (где используются лишь встроенные средства для мержа, а все, что снаружи а-ля Гит/Меркуриал и прочее видит лишь блобы), такое случается. И чаще, чем хотелось бы. Ну и накатывать на живую. Каждый раз, когда я вижу, как на живой продакшен накатывают без его остановки обновления и не делая бэкапы, у меня аж сердце схватывает. Т.е. кто-то перестрахуется лишний раз и потеряет время, а кто-то сразу в прод.
Но количество ошибок велико. Как правило, довольно простых. И возникают они, как раз, из-за фантастической скорости разработки. А затереть чужой обновленный код из своей старой ветки — это вообще едва ли не через день. Да, кто-то скажет, система контроля версий и т.д., но учитывая реальность (где используются лишь встроенные средства для мержа, а все, что снаружи а-ля Гит/Меркуриал и прочее видит лишь блобы), такое случается. И чаще, чем хотелось бы. Ну и накатывать на живую. Каждый раз, когда я вижу, как на живой продакшен накатывают без его остановки обновления и не делая бэкапы, у меня аж сердце схватывает. Т.е. кто-то перестрахуется лишний раз и потеряет время, а кто-то сразу в прод.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По шестому правилу с Вашей критикой согласен.
Что касается остальных — не согласен. Мне, в свою очередь, кажется, что Вы недооцениваете такое понятие как архитектура проекта. Возможно, недопонимаете это понятие. Отсюда недопонимание роли архитектора.
На мой взгляд, архитектор — это человек, который определяет, какие классы/объекты будут в программе, какие у них методы, какие действия выполняются объектами с помощью этих методов. Он объясняет сотрудникам, какие классы нужны, как он их объединит для решения задачи. После этого те, кто понял архитектуру, делают свои предложения по архитектуре, кто не понял — идут реализовывать свои ТЗ.
Тут, конечно, возможно недопонимание. В сложном проекте могут быть десятки и даже сотни подсистем, и все они должны слаженно работать. Для простых проектов архитектура часто очевидна и архитектор почти не нужен.
Отчасти Вы правы — статья написана в результате работы в одной команде, и под впечатлением того, как делать не надо. Советы написаны по принципу «от противного». В моей команде пытались уравнивать «звёздного» программиста с просто хорошими, отсюда возникло правило 6. Безусловно, категоричность не доведёт до добра, но я начинаю понимать японцев, которые обижаются, если идущего, скажем, в отдел кадров сотрудника попросить захватить с собой документ для отдела кадров — для этого есть курьер. Конечно, ключевой показатель работы — это продукт, и для его достижения правила нужно иногда нарушать. Но нельзя строить работу так, чтобы нарушение правил было нормой. Ну и, конечно, у каждого правила есть разумные границы применения.
Статья, в основном, адресована тем, кто путает «ответственность, лидерские качества и умение повести за собой людей» с наличием прямых рук для создания продукта. Творческим людям нужные творческие задачи и творческая мотивация, тогда они создадут классный продукт. «Зажечь» их может только творческий человек, азартный опытный разработчик. Он, правда, не должен навязывать исполнителям свои методы решения задачи. Его задача — архитектура, плюс некоторые предложения по реализации. Если исполнитель хочет по-другому, пусть делает по-другому. Хорошая архитектура — это когда подсистему можно переписать с нуля, использовав только ТЗ, заменить её в проекте, и проект продолжит работу как и раньше.
Что касается остальных — не согласен. Мне, в свою очередь, кажется, что Вы недооцениваете такое понятие как архитектура проекта. Возможно, недопонимаете это понятие. Отсюда недопонимание роли архитектора.
На мой взгляд, архитектор — это человек, который определяет, какие классы/объекты будут в программе, какие у них методы, какие действия выполняются объектами с помощью этих методов. Он объясняет сотрудникам, какие классы нужны, как он их объединит для решения задачи. После этого те, кто понял архитектуру, делают свои предложения по архитектуре, кто не понял — идут реализовывать свои ТЗ.
Тут, конечно, возможно недопонимание. В сложном проекте могут быть десятки и даже сотни подсистем, и все они должны слаженно работать. Для простых проектов архитектура часто очевидна и архитектор почти не нужен.
Отчасти Вы правы — статья написана в результате работы в одной команде, и под впечатлением того, как делать не надо. Советы написаны по принципу «от противного». В моей команде пытались уравнивать «звёздного» программиста с просто хорошими, отсюда возникло правило 6. Безусловно, категоричность не доведёт до добра, но я начинаю понимать японцев, которые обижаются, если идущего, скажем, в отдел кадров сотрудника попросить захватить с собой документ для отдела кадров — для этого есть курьер. Конечно, ключевой показатель работы — это продукт, и для его достижения правила нужно иногда нарушать. Но нельзя строить работу так, чтобы нарушение правил было нормой. Ну и, конечно, у каждого правила есть разумные границы применения.
Статья, в основном, адресована тем, кто путает «ответственность, лидерские качества и умение повести за собой людей» с наличием прямых рук для создания продукта. Творческим людям нужные творческие задачи и творческая мотивация, тогда они создадут классный продукт. «Зажечь» их может только творческий человек, азартный опытный разработчик. Он, правда, не должен навязывать исполнителям свои методы решения задачи. Его задача — архитектура, плюс некоторые предложения по реализации. Если исполнитель хочет по-другому, пусть делает по-другому. Хорошая архитектура — это когда подсистему можно переписать с нуля, использовав только ТЗ, заменить её в проекте, и проект продолжит работу как и раньше.
Совет №11 – поставьте time tracking :)
Из этой статьи я узнал, что работаю не только программистом, но еще и архитектором, дизайнером и менеджером, попутно переключаясь с одной задачи на другую в течении дня. Где-то в этой жизни я повернул не туда. Стоит скинуть эту статью своему руководству.
Эта статья великолепна. Особенно правила 1,2,3,4,5,6,7,8,9.
Это точно не для России
если им прямо сказать: «Вы нам не подходите… не вопрос минимум 1 оклад, не хотите то 100500 причин начиная от косяков в трудовом договоре до условий труда, аттестации рабочего места, охраны труда и пр. он лайн обращение в трудовую инспекцию и проверки задолбают работодателя.Надо соответствовать названию — скот
Наказывать пасущих скотов надо рублём
если им прямо сказать: «Вы нам не подходите… не вопрос минимум 1 оклад, не хотите то 100500 причин начиная от косяков в трудовом договоре до условий труда, аттестации рабочего места, охраны труда и пр. он лайн обращение в трудовую инспекцию и проверки задолбают работодателя.Надо соответствовать названию — скот
Наказывать пасущих скотов надо рублём
Девятое правило очень интересное. Особенно интересно, как же заманить в свою компанию "более лучших", и как определить, что ты, в пылу поисков, не решил уволить лучших из тех, кто в принципе может согласиться в ней работать.
Девятое правило, это типичная отрицательная спираль развития.
Вместо того, чтобы привлекать хороших специалистов (условиями работы, проектами и т.д.), отсеивают «плохих».
Большой простор для «подковерных игр» и создания «серпентария».
:-)
Вместо того, чтобы привлекать хороших специалистов (условиями работы, проектами и т.д.), отсеивают «плохих».
Большой простор для «подковерных игр» и создания «серпентария».
:-)
На двух прошлых местах работы наблюдал такую тенденцию: самые лучшие работники растут быстро и либо а) в большой компании не принято так часто повышать в должности и им приходится уходить либо б) в маленькой компании нет возможности платить большую з/п и им приходится уходить. При этом работники «ниже среднего» очень держатся за свои «насиженные» места и старательно изображают деятельность (как вариант: покупают печеньки, ходят на субботники, не опаздывают и т.д.).
Видимо, автор ведет речь о борьбе с плохими работниками. Он так же упоминает что надо заменять их хорошими, но самое главное тут — как заполучить этих хороших? Я это видел только один раз на текущем месте (стартап) — разработчиков всего трое на три подсистемы, поэтому цена ошибки очень велика, и набрали лучших из тех, что нашли. Которых не нужно мотивировать дополнительно, достаточно внутренней мотивации и желания не подвести команду. Но как эту атмосферу равенства и братства сделать в команде хотя-бы в 10 человек, уже не представляю — все равно кто-то будет отставать.
Видимо, автор ведет речь о борьбе с плохими работниками. Он так же упоминает что надо заменять их хорошими, но самое главное тут — как заполучить этих хороших? Я это видел только один раз на текущем месте (стартап) — разработчиков всего трое на три подсистемы, поэтому цена ошибки очень велика, и набрали лучших из тех, что нашли. Которых не нужно мотивировать дополнительно, достаточно внутренней мотивации и желания не подвести команду. Но как эту атмосферу равенства и братства сделать в команде хотя-бы в 10 человек, уже не представляю — все равно кто-то будет отставать.
Если разработчик сидит на совещании — он не работает.Разработчики участвуют в оценке проектов, в подготовке технического решения (не всегда это может сделать аналитик и не всегда он есть), должны уметь доносить результаты своей работы, объяснять свои идеи — для меня, и как для разработчика, и как для руководителя, это наиболее эффективный способ. Вы просто не зовите их на все совещания.
Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.Если бы так, то факапов со сроками и качеством было бы гораздо меньше. Помимо дисциплины необходим навык управления командой, процессом, работы с мотивацией,
При этом вы говорите:
Поэтому потрудитесь распределить задачи качественно, чтобы избежать неприятных сюрпризов.Это не может делать просто «любой мало-мальски дисциплинированный человек» — проверено. Вы сами себе противоречите.
Спасибо за ответ. Я подразумевал, что задачи распределяет архитектор. Он же назначает сроки. Он же участвует в совещаниях, посвященных технической стороне продукта. Если совещаются по срокам, он туда не идёт. Он же назначает премии.
В ваших словах противоречие — «назначает сроки», " Если совещаются по срокам, он туда не идёт.".
Ну как бы архитектор, по вашему, ответственен за сроки.
Т.к. он их поставил и это его зона ответственности.
И при этом он не идет на совещание по срокам.
Обычно на таких совещаниях (если они с заказчиками) можно «отстоять» свои сроки.
Ну как бы архитектор, по вашему, ответственен за сроки.
Т.к. он их поставил и это его зона ответственности.
И при этом он не идет на совещание по срокам.
Обычно на таких совещаниях (если они с заказчиками) можно «отстоять» свои сроки.
Что значит «ответственен»? Мне непонятна эта абстракция слова «ответственен».
Ответственность — это фикция. Квалификация — это гарантия результата.
Квалифицированный сотрудник сделает задачу при нормальной ответственности. Неквалифицированный руководитель провалит проект при самой высочайшей его ответственности.
Отстаивать сроки должен представитель администрации. Который должен быть поставлен в известность о вариантах разработки. О том, сколько работы необходимо ещё выполнить. Стоит понимать, что ускорение разработки возможно только в одном случае — если перегрузить работников. Это можно делать краткосрочно, за доплату и с предоставлением последующего отдыха. За это заказчик должен доплатить. Соответственно, руководитель должен иметь представление о вариантах развития событий. Архитектор должен эти варианты ему обозначить. Какой режим и срок разработки нормальный, какой — интенсивный, какой — сверхинтенсивный, какой не реален. Если обсуждается изменение ТЗ в части возможностей продукта — тогда архитектор нужен. Если говорить про сроки — все варианты развития событий (в т.ч. вариант предоставления сырого макета с последующей доводкой) должен знать администратор.
Основной посыл статьи в том, что работа делится на две части — административную и техническую. И администратор в продукте играет почти никакую роль, лишь подбирает технические кадры. Соответственно, технари тоже должны быть от административных вопросов изолированы.
Ответственность — это фикция. Квалификация — это гарантия результата.
Квалифицированный сотрудник сделает задачу при нормальной ответственности. Неквалифицированный руководитель провалит проект при самой высочайшей его ответственности.
Отстаивать сроки должен представитель администрации. Который должен быть поставлен в известность о вариантах разработки. О том, сколько работы необходимо ещё выполнить. Стоит понимать, что ускорение разработки возможно только в одном случае — если перегрузить работников. Это можно делать краткосрочно, за доплату и с предоставлением последующего отдыха. За это заказчик должен доплатить. Соответственно, руководитель должен иметь представление о вариантах развития событий. Архитектор должен эти варианты ему обозначить. Какой режим и срок разработки нормальный, какой — интенсивный, какой — сверхинтенсивный, какой не реален. Если обсуждается изменение ТЗ в части возможностей продукта — тогда архитектор нужен. Если говорить про сроки — все варианты развития событий (в т.ч. вариант предоставления сырого макета с последующей доводкой) должен знать администратор.
Основной посыл статьи в том, что работа делится на две части — административную и техническую. И администратор в продукте играет почти никакую роль, лишь подбирает технические кадры. Соответственно, технари тоже должны быть от административных вопросов изолированы.
Ответственность. Это значит, что каждый делает свое дело и не мешает делать свои дело другим.
Сроки, всегда можно «подвинуть», лишь бы была вменяемая аргументация.
Сам участвовал в совещаниях по сроком. Аргументированный ответ, когда на плане показывается, что «нельзя впихнуть не впихуемое», т.к. работ набирается в полтора раза больше, чем предполагал заказчик, вполне может «подвинуть сроки» для исполнителя.
Сроки, всегда можно «подвинуть», лишь бы была вменяемая аргументация.
Сам участвовал в совещаниях по сроком. Аргументированный ответ, когда на плане показывается, что «нельзя впихнуть не впихуемое», т.к. работ набирается в полтора раза больше, чем предполагал заказчик, вполне может «подвинуть сроки» для исполнителя.
Ответственность это фикция уже потому, что продукт делается за фиксированное время. Независимо от ответственности. Производительность труда довольно стабильная штука. Постоянно работать по 16 часов можно недели две, потом производительность падает, и всё, приехали. Но зависимо от квалификации. Можно пару раз пойти не тем путём, сжечь все силы на переработках, а проблема будет в архитектуре. Можно выбрать удачную архитектуру и в рабочем режиме, без переработок, заполнить её функционалом. Вопрос в том, кого Вы выбрали руководителем проекта.
Опять же, сбоящая подсистема тормозит всю команду, т.к. она стопорит продукт, и архитектор вынужден участвовать в поиске ошибок. Поэтому квалифицированный кодер для проекта лучше неквалифицированного. Вопрос в том, кого Вы набрали в исполнители.
Если архитектор налажал со сроками/архитектурой/ТЗ для исполнителей, то никакая ответственность тут не поможет. Вы ведь его не расстреляете, и деньги с него не возьмёте, и что Вы хотите от него услышать на совещании? Толпа народа вызовет у него лишь желание изворачиваться, и проблема, скорее всего, будет от вас скрыта до дедлайна и после дедлайна и так далее. Лучше переговорить с ним доверительно с глазу на глаз, переговорить доверительно с другими «звёздами» и ведущими, использовав коммуникационные навыки, и уже потом без него принимать решение о дальнейших действиях — либо менять архитектора на другого ведущего спеца из команды, либо… Либо докладывать начальству о катастрофе в разработке проекта.
Опять же, сбоящая подсистема тормозит всю команду, т.к. она стопорит продукт, и архитектор вынужден участвовать в поиске ошибок. Поэтому квалифицированный кодер для проекта лучше неквалифицированного. Вопрос в том, кого Вы набрали в исполнители.
Если архитектор налажал со сроками/архитектурой/ТЗ для исполнителей, то никакая ответственность тут не поможет. Вы ведь его не расстреляете, и деньги с него не возьмёте, и что Вы хотите от него услышать на совещании? Толпа народа вызовет у него лишь желание изворачиваться, и проблема, скорее всего, будет от вас скрыта до дедлайна и после дедлайна и так далее. Лучше переговорить с ним доверительно с глазу на глаз, переговорить доверительно с другими «звёздами» и ведущими, использовав коммуникационные навыки, и уже потом без него принимать решение о дальнейших действиях — либо менять архитектора на другого ведущего спеца из команды, либо… Либо докладывать начальству о катастрофе в разработке проекта.
В статье отсутствует важная деталь.
Автор забыл объяснить зачем руководителю соблюдать все придуманные им правила.
Автор забыл объяснить зачем руководителю соблюдать все придуманные им правила.
И правильно. Это статья, а не пропаганда.
Соблюдать или нет — каждый решает сам, исходя из своих знаний и опыта.
Соблюдать или нет — каждый решает сам, исходя из своих знаний и опыта.
Если руководитель хочет решить поставленную задачу, ему следует проанализировать предложенные правила. Правда пара комментариев получилась лучше статьи. Правила слишком бескомпромиссные. Для рутины действительно нужны обычные разработчики, они не так склонные менять место работы. В сочетании с опытом они являются хоть какой-то страховкой от кадровых катаклизмов (типа увольнения нескольких ключевых спецов, из которых я предложил собрать команду).
Причем тут скоты?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как пасти скотов. Советы руководителю подразделения разработчиков