Итак, правила:
Правило первое — чтобы хорошо руководить разработкой, необходимо быть разработчиком.
Это правило незыблемое. Разработка — сложный процесс, и грамотно управлять им может только тот, кто знает этот процесс изнутри. Другого не дано. Если Вы никогда не разрабатывали сложных систем, Вы не можете качественно руководить разработкой. При этом вы можете руководить разработчиками. Но для создания продукта Вам придётся подобрать компетентных людей, работу которых Вы будете обеспечивать. Я знал немало руководителей, которые полностью перекладывали технические вопросы на подчинённых, восхищались людьми, умеющими делать технику, и задавали только два вопроса: «Когда будет готово?» и «Что необходимо для работы?». Это отличный стиль руководства для неспециалиста. Подводный камень здесь только один — кадровая политика. Ошибка в кадровой политике может вылиться в срыв проекта и потерю должности. Если с кадрами повезло, то остаётся лишь обеспечить их работу. О том, как её обеспечивать — читайте следующие правила.
Правило второе — каждый разработчик должен заниматься только своей работой, а если говорить точнее — только принятием технических решений.
Если это программист — он должен писать программу. Если это электронщик — он должен рисовать схемы. Он не должен писать служебные записки, подавать перечни на закупку и прочее. Он должен только принимать технические решения в области своей компетенции, и делать это в совершенстве. Это же касается и программирования, и конструирования. Велик соблазн использовать специалиста ещё для чего-нибудь. Но в этом случае Вы провоцируете у него прокрастинацию и гарантированно снижаете его производительность и квалификацию. На переключение между разнородными задачами необходимо до 2-х дней, если разработчик является оптимистом и не впадает в уныние от того, что его оторвали от недоделанной задачи. Нормальный человек при переключении между задачами теряет до недели времени. И в обратную сторону снова теряет эту неделю. Поэтому потрудитесь распределить задачи качественно, чтобы избежать неприятных сюрпризов.
Правило третье — при разработке сложного продукта необходима иерархия принятия технических решений.
Сложный продукт требует высококлассных специалистов. Но все специалисты разные. И хороших мало. И стоят они дорого. Поэтому в разработке нужна иерархия. Должен быть системный архитектор, который почти не занимается непосредственно разработкой, но ставит конкретные задачи исполнителям. Это высококлассный специалист, который стоит дорого. Возможно, он стоит дороже некоторых руководителей. И уж точно для предприятия он ценнее многих руководителей. Должно быть несколько (от одного до бесконечности, в зависимости от сложности проекта) суперисполнителей. Это высококлассные специалисты, которые имеют представление о структуре проекта, и могут выполнять функции архитектора. Они разрабатывают самые ответственные части системы. Также нужны обычные разработчики. Они выполняют обычную работу под руководством архитектора и суперисполнителей, их легко заменить, зарплата у них вполне обычная. Они делают то, что называется рутиной. Для оформления текстовой технической документации необходимы технические писатели. Для закупки расходных материалов нужен секретарь или помощник руководителя. Эти функции может выполнять руководитель, если он не является техническим специалистом, и не занят непосредственно разработкой продукта. Как в анекдоте: «покорми собак и ничего не трогай».
Правило четвертое — не ставьте одному специалисту разнородные задачи.
В рамках одного проекта разработчик должен быть или только программистом, или только архитектором одной или нескольких подсистем, или только электронщиком. Он должен делать одно дело, и доводить это до совершенства. Нельзя сочетать разработку сложных систем разного рода в одно и то же время. Тем более не следует использовать одного специалиста для таких задач как программирование и электроника одновременно. Изредка электронщики умеют программировать, конструкторы — составлять электрические схемы. Не следует считать это нормой — это отклонение. Если человеку интересно — он может некоторое время совмещать две профессии, но рано или поздно это приводит к утомлению, сильно снижает производительность труда. Поэтому, если хотите получить хорошую работу, забудьте про «универсальных специалистов». Это утопия.
Правило пятое — не всякая ошибка есть катастрофа.
В процессе разработки программ и устройств всегда будут ошибки. Мы всего лишь люди, и мы слишком несовершенны. Ошибаются все. Любой хороший технарь это знает. Именно для этого существуют стадии разработки с макетированием, испытаниями, опытными образцами и так далее. Показателем плохой работы является лишь статистика ошибок и их уровень (есть ошибки детские, а есть явления, по которым можно диссертацию написать). Проблема в том, что руководитель, не являющийся техническим специалистом, этого не понимает. Он считает, что любая ошибка — показатель непрофессионализма. И начианает распекать совсем не тех людей и совсем не за то, за что следует.
Правило шестое — разработчики бывают разные.
Бывают способные, а бывают обычные. Способный разработчик эффективнее обычного раз в десять. Это не шутка, это общеизвестная оценка, довольно старая. Ошибка многих руководителей в том, что они считают специалистов в штуках. А на самом деле в подрезделении есть ключевые специалисты, которые стоят десяти разработчиков. И ошибки у них встречаются редко, а если и встречаются, то очень неочевидные. И отношение к ним должно быть особенное.
Правило седьмое — разработчики должны общаться на технические темы за кружкой чая.
Вот так. Если разработчик сидит на совещании — он не работает. Если он обсуждает новые технологии с коллегами за кружкой чая — он работает. Такие разговоры часто вдохновляют его на новые технические решения, которые он опрообует в рабочее время, после работы, ночью или в выходные. Задача руководителя — поддерживать традиции творчества в подразделении.
Правило восьмое (невыполнимое) — рыночные принципы должны распространяться не только на зарплаты специалистов, но и на зарплаты руководителей.
Если хорошего программиста труднее найти, чем среднего руководителя, то и получать он должен большую зарплату, чем руководитель нижнего звена. От него пользы больше. Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек. А вот написать сложную программу может далеко не каждый программер. Это не значит, что программист должен зарабатывать больше генерального директора. Конечно, если он не гений разработки. Но хороший программист вполне может зарабатывать больше начальника отдела.
Правило девятое (противозаконное) — ТК РФ мешает работе.
Все эти должности-оклады, все эти обязанности — это фикция. Специалисты отличаются по качеству. Есть специалисты высококлассные, есть специалисты обычные. И если плохого спеца уволить можно, состряпав комиссию, которая выявит его несоответствие занимаемой должности, то обычного специалиста уволить невозможно, если он не совершает грубых дисциплинарных проступков. Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного. Хотя, на мой взгляд, испытательный срок в три месяца вполне достаточен для того, чтобы понять, что за специалист к Вам устраивается. Правда неудобный ТК РФ отлично компенсируется сговорчивостью работников — большинство из них согласится написать заявление по собственному желанию, если им прямо сказать: «Вы нам не подходите».
Вот, пожалуй, и всё. Предлагаю коллегам добавить свои пожелания в комментариях.
Если Вам показалось, что во мне говорят комплексы, что я предлагаю разрешить работникам пить чай, опаздывать на работу, не получать нагоняи за ошибки и зарабатывать больше руководителя, значит Вы ничего не понимаете в разработке. Эти правила имеют свою область применения, и передозировка приведёт именно к тому, что Вам показалось. Но умение чувствовать эту грань, отделяющую творческую атмосферу от анархии, и есть показатель хорошего руководителя подразделения разработчиков.
Комментарии (108)
iit
16.03.2017 11:26+1Вопрос к автору — как вы определите какой специалист обычный, какой высококласный а какой плохой?
Durimar123
16.03.2017 12:49-4Проблема в том что ты не сказал для кого специалист должен быть классным…
Например для конторы оутсорсинга дело обстоит так.
Вариант 1
Час работы senier 50$ ему отдают 25$.
Он выполнил работу за 10 часов. профит конторы 250$
Вариант 2
Час работы middle 30$ ему отдают 15$.
Три мидла выполнили работу за 20 часов и принесли конторе 900$
Ну и какой специалист высококлассный для руководства конторы?
zip_zero
16.03.2017 12:57+5Есть задача. Есть две оценки: 10 часов, 1 человек (цена — $500) и 20 часов, 3 человека (цена — $1800).
Риторический вопрос: что выберет заказчик?Durimar123
16.03.2017 13:00-3Риторический вопрос: что выберет заказчик?
Риторический ответ: 10% как бонус скорее всего склонит его к третьему варианту — с джуниорами.ivkomn
16.03.2017 15:20Так и есть. Это же аутсорсинг, никаких перспектив, никакого развития. Выполнили поставленную задачу и трава не расти. Самая мякотка — выполнить задачу так, что бы засадить в неё баг(сделать не до конца) и за решением этого бага придут к тебе.
ikovrigin
16.03.2017 18:20+1Простите вы заказчику продаете сотрудника или все же результат работы? Если стоимость работ для заказчика 1800, то не трудно посчитать что senior получив свои 250 баксов заработал для фирмы 1550. Плюс к этому в некоторых случаях заказчик готов платить больше за более быстрое выполнение работы, но не наоборот. Иначе выгоднее всего было нанимать людей которые вообще не умеют программировать время выполнения работы этими сотрудниками стремиться к бесконечности… PROFIT.
nikolayv81
22.03.2017 15:57Крупные "аутсорсеры" сначала заходят к заказчику, а потом уже идёт компромисс при обработках и поддержке.
indestructable
16.03.2017 13:21Смотреть нужно не на текущую рентабельность, а на рентабельность проекта (с учетом багфиксов, запуска, поддержки). А так да, для фриланс-заказов на 10 часов выгоднее всего наиболее дешевый из подходящих, как уже указали ниже.
indestructable
16.03.2017 13:18Для этого есть правило первое :)
По сути, формальных критериев для этого нет (и я считаю, не нужно их искать, иначе получите не хороших, а соответствующих). Но по работе и по отношению в команде это видно, и этого достаточно.
MurzikFreeman
16.03.2017 12:08+3Бывают способные, а бывают обычные. Способный разработчик эффективнее обычного раз в десять.
Зарплата бывает хорошая, а бывает обычная. За хорошую зарплату я работаю эффективнее раз в десять чем за обычную. Так какой же я разработчик?max1gu
16.03.2017 18:01+6где-то с 80-х годов было подмечено, что производительность специалистов уровня от среднего и выше не зависит от зарплаты. Отсюда все эти социальные пакеты, игровые комнаты в офисах, 20% на личные проекты и прочая неденежная мотивация.
Так что вы скорее всего разработчик ниже среднего или зарабатываете очень мало относительно в среднем по рынку.MurzikFreeman
17.03.2017 10:17Нет, у меня средний уровень. Под словом «обычная» я имел в виду именно среднюю по рынку, если брать мой регион. Если брать среднюю по всей планете, то да, просто мизер.
Не знаю что там подметили в 80-х, но по моим наблюдениям, мантру «деньги не мотиватор», продолжают повторять только в конторах с зарплатами ниже среднего. Когда компания не может замотивировать сотрудника материально, она начинает искать способы подмены ценностей. Все эти игровые комнаты, тимбилдинги и и прочие печеньки на кухне. А если сотрудник не мотивируется мишурой и продолжает просить больше денег, он у них сразу плохой специалист с низкой мотивацией от которого нужно избавляться. Ну ясен пень, все хотят получить сеньора за три бакса. Только получают они в итоге специалиста, который 50% рабочего времени тратит на развитие себя для поиска другой работы, а не на то, чтобы сделать больше для своей компании.
Areso
18.03.2017 11:37А если в компании нет ни денег, ни мишуры (игровые комнаты, тимбилдинги, и прочие печеньки)?
Тогда, вероятно, сотрудник занимается на 75% собственным развитием?
Interfere
16.03.2017 12:15+3Если разработчик сидит на совещании — он не работает.
в рамочку и на стену. самое главное правило, которое должны усвоить любители совещаний.wladyspb
16.03.2017 16:37+3Вот с этим утверждением не согласен — совещания тоже бывают разные, например у нас они как правило неформальные и технические, на них обсуждается как прийти к консенсусу между пожеланиями менеджеров и возможностями разработчиков, выбираются и обсуждаются технические решения. На совещание на котором обсуждаются рыночные нюансы или ещё что-то не относящееся к разработке — программистов и не позовут)
aquamakc
17.03.2017 09:44+1Вот именно, совещания бывают разные, присутствие специалиста на некоторых из них в интересах самого-же специалиста, например, когда решается вопрос о развитии системы над которой специалист работает. Если он не принимает в нём участие, то решения принимают менеджеры разной степени эффективности исходя из собственного понимания, опыта и тараканов.
Vjatcheslav3345
16.03.2017 12:55+2Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного.
Правило № 9 очень интересное — оно означает (гауссово распределение), что нужно систематически искать, выявлять и увольнять почти всех средне-нормальных спецов.
Если в программировании это как то (и в специальных случаях — типа сильного роста зарплаты для нового сотрудника) и работает, то вот в других сферах — вряд ли.
А так нужные "звёзды" уволятся сами; им даже не нужно искать более доходное место для работы — к ним занимают очередь с предложениями.
DexterHD
16.03.2017 13:27+3Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного. Хотя, на мой взгляд, испытательный срок в три месяца вполне достаточен для того, чтобы понять, что за специалист к Вам устраивается.
1. Большая текучка в рамках 3 месяцев в итоге приведет к тому, что на работу будут приходить разве что вообще ни какие специалисты, потому как хорошие, а там более отличные специалисты, такие конторы просто проходят мимо. И поверьте как правило в комьюнити люди знают что на самом деле происходит в тех или иных компаниях. Земля как говорится слухами полнится.
2. Хорошие специалисты как правило амбициозны и ищут пути для развития и повышения, какой смысл тратить время и силы на вашу шарагу если через год другой тебя просто попросят со словами «вы нам не подходите мы нашли лучше».
Germanets
16.03.2017 13:47+2Есть ещё один замечательный момент — чтобы программисту, в отличии от грузчика, включиться в работу компании и начать приносить пользу — нужно несколько месяцев, а то и пол года потратить на изучение продукта, разрабатываемого в компании, в течении которого как его польза, так и польза от других разработчиков его отдела будет меньше, чем была до перехода его в компанию. Будет тратится время на изучение и структуры проекта, и на консультации с более опытными товарищами, изучение части используемых инструментов и т.д… В результате может получиться, что разработчика уволят к тому времени, когда он только-только начал окупать вложенные в него средства.
teemour
16.03.2017 15:11-3Да вы что опухли что ли там все. Какие такие несколько месяцев. Разработчик может приносить пользу уже через две недели, а через несколько месяцев может делать всё что надо.
Но может и не приносить вообще никогда, а за эту зарплату ещё и немножечко вредить.3aicheg
17.03.2017 04:43+1Бывший начальник, принимая меня на работу, очень хотел клятв, что я никуда не сбегу: «А то ж знаем мы вас, пока тут осмотритесь, да обучитесь, да освоитесь, через год только пользу приносить начнёте, а уже возьмёте и уйдёте в другое место!» Ладно, приняли, задачу поставили, спрашивает, когда будет готово? Говорю, ну, прямо щас не готов ответить, надо же осмотреться и освоиться, вы же сами сказали, что на это уйдёт год. «Шшшштоаа?!!?! Какой ещё год, мы вам не можем такого позволить! Максимум у вас есть неделя на это!» Так я узнал, что поговорка «без году неделя» имеет совершенно конкретное, практическое применение.
Ivan22
17.03.2017 16:13начальник сказал «пользу» подразумевая «прибыль». Тогда все сходится. Таски-то делать уже через неделю можно, а вот с прибылью — через год. А может и никогда
White_Scorpion
17.03.2017 15:28Речь в тексте статьи идёт о сложных проектах — 2 недели это если он собирается под условной пользой считать: подметание пола в офисе и тому подобные вещи.
ivkomn
16.03.2017 15:30Germanets не совсем так. В большинстве случаев человек начинает
приносить пользуделать годные коммиты через неделю-месяц от начала действия трудового договора. Наблюдал такое много раз на собственном и чужом примере в проекта сложностью от 1-го пид-регулятора(с набором коммуникаций по уровням) до 50к java кода, обрабатывающего(хранение, анализ) фискальные сообщения.
Хотя да, в «хрестоматии» написано, увеличение кол-ва разработчиков сокращает:
— скорость команды
— ускорение команды
в главе про «смоляные ямы», кажется.little
16.03.2017 18:22+1человек начинает приносить пользу делать годные коммиты через неделю-месяц
Да, но это совершенно не означает, что он полностью освоился в проекте и готов подменить любого «старичка».ivkomn
16.03.2017 20:43Подменить нет(про это и не было ра3говора), но *поль3у*! поль3у-то приносит… вёдрами ))
haiflive
16.03.2017 15:47я думаю автор немного топорно выразился, и имел в виду что за период испытательного срока отчётливо видно приносит работник пользу или он особо ничего не делает или создаёт видимость бурной деятельности, к тому же он может отнимать достаточно много времени у других работников допуская грубые ошибки, которые эти самые работники после него разбирают и объясняют ему что так делать не надо, нет я ни в коем случае не говорю что все люди идеальны, но если человек дилетант и далеко не соответствует квалификации, то такого программиста не специалист не вычислить никогда, а то и подружится с ним потому что он постоянно мило беседует с ним и рассказывает много интересных технических «штук»
так же есть вариант «не сошлись характером», — тоесть руководителю просто не удалось нормально замотивировать человека и направить его энергию в нужное руслоivkomn
16.03.2017 16:04если человек дилетант и далеко не соответствует квалификации, то такого программиста не специалист не вычислить никогда, а то и подружится с ним потому что он постоянно мило беседует с ним и рассказывает много интересных технических «штук»
Особо печально, когда первый — генеральный директор, второй — технический. А тот, с кем не сошлись характерами, он какие-то «странные штуки» говорил и вообще в «облаках витает»
redfs
16.03.2017 13:58+17Дочитав, я обнаружил, что статья прекрасна уже тем, что в ней нет ни слова про KPI и Agile :)
v2065925
16.03.2017 13:58-1Это безусловно идеальные правила для идеального мира. Но в условиях бизнеса не выжить, без нарушений правил и оптимизации первых трех.
v2065925
16.03.2017 15:39-2И более полное название статьи: Как пасти скотов. Советы руководителю подразделения разработчиков ОТ ИСПОЛНИТЕЛЕЙ. Потому как позиция руководителя будет совсем иной, и он так же может написать обратку в сторону ленивых исполнителей)
habradante
16.03.2017 14:17+3Ну просто куча замечаний…
«На переключение между разнородными задачами необходимо до 2-х дней,… Нормальный человек при переключении между задачами теряет до недели времени»
Вы уж определитесь, 2 дня или неделя, и откуда вообще такие цифры, из чьей головы?
«Если разработчик сидит на совещании — он не работает»
Если ведущий разработчик проводит совещание с коллегами на тему того как и куда им дальше двигаться в разработке, то это (ВНЕЗАПНО) и совещание и работа! Так же ведущий разработчик может и должен привлекаться на этапе ТЗ, для правильной оценки уровня технических задач, степени их реализуемости и сложности. И да, это все тоже делается на совещаниях, и да, в этот момент этот специалист работает.
«Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.»
Так считают все посредственные руководители. «Это же элементарно, что там делать? Раздал задачи и только галочки в расписании проставляй.»
«Если хорошего программиста труднее найти, чем среднего руководителя, то и получать он должен большую зарплату, чем руководитель нижнего звена.»
То руководитель средний, то нижний… Опять сумбур какой-то. Зарплата специалисту зависит от возможностей компании и той пользы, которую приносит данный специалист для этой компании. А так да, я бы тоже хотел чтобы мне только за регалии деньги платили.
«Есть специалисты высококлассные, есть специалисты обычные. И если плохого спеца уволить можно, состряпав комиссию, которая выявит его несоответствие занимаемой должности, то обычного специалиста уволить невозможно, если он не совершает грубых дисциплинарных проступков. Но увольнять его нужно. И искать на его место более лучшего, более способного и квалифицированного.»
Ура, мы добрались до сути, оказывается, есть только ВЫСОКОКЛАССНЫЕ и ОБЫЧНЫЕ. Причем «обычные»=«плохие».
Очень хочется спросить у автора: «Вы когда-нибудь сами-то руководили командой, где одни „звезды“?»
В реальной жизни, на проект требуются не только высококлассные специалисты, но и вполне себе обычные, т.к. «рутину» высококлассные специалисты делают плохо, и это их демотивирует. А еще в команде есть условные «джуниоры», которые замотивированы на решение простых задач, чтобы на них научиться делать более сложные.
И вообще, вопрос формирования команды, куда более сложен, чем «давайте наймем высококлассных спецов за овермного денег и они нам все напишут».avost
16.03.2017 16:12-2Вы ведь "начальник"?
habradante
16.03.2017 17:00Нет
avost
16.03.2017 21:45Очень странно тогда, что в таких простых вещах запутались. "средний руководитель нижнего звена" — что тут может вызвать трудности? Или переключение нормального человека в неделю, а крутого в 2 дня. Недоумеваю...
habradante
17.03.2017 10:30+1Кто это «средний руководитель нижнего звена»? Можно пример?
Переключение контекста у человека происходит за 15 минут. Это эмпирическая величина. Если требуется неделя, или даже два дня, то… это диагноз, увы.
А уж мыслить категориями «нормальный», «крутой», на техническом ресурсе… это как направление в море пальцем показывать. Плюс у каждого свои понятия «крутой» и «нормальный».avost
17.03.2017 15:09Кто это «средний руководитель нижнего звена»? Можно пример?
ПМ? "Средний" относится к способностям, "нижнего звена" — к должности :)
А уж мыслить категориями «нормальный», «крутой», на техническом ресурсе…
А у вас есть технические, точные и метрологически выверенные шкалы квалификаций и общепринятые методики их оценки? Поделитесь, пожалуйста. Думаю, всем будет интересно!
это как направление в море пальцем показывать.
Не всякие величины могут быть градуированы в абсолютных значениях.
Плюс у каждого свои понятия «крутой» и «нормальный».
Но, даже те, которые не могут быть градуированы, вполне могут быть ранжированы и пригодны для оценки, анализа и прочей работы с ними. В рамках заданной выборки "крутой" ранжируется выше "нормального". Да, это действительно почти всё, что об этом можно сказать. И это нормально. Самые основы предмета, который во времена оны преподавался под названием "системный анализ", а сейчас, в связи девальвацией этого термина мененджерами, называется "системной инженерией". Его перестали преподавать? Куда катится образование… :(
habradante
17.03.2017 15:24+1«ПМ? „Средний“ относится к способностям, „нижнего звена“ — к должности :)»
ПМ в компаниях может быть значительно выше «нижнего» звена, в зависимости от проекта, который он реализует.
«А у вас есть технические, точные и метрологически выверенные шкалы квалификаций и общепринятые методики их оценки? Поделитесь, пожалуйста. Думаю, всем будет интересно!»
Нет, у меня нет, но и автор свои критерии определения «нормальности» и «крутости» не привел. У меня, например, «нормальным» считается специалист, который справляется со своими обязанностями, «хорошим» — который делает немного сверх и может в смежные области, а «крутой» — это тот кто эксперт в своей области, плюс понимает потребности бизнеса в целом и в создаваемом продукте, в частности. Опять-таки, какие критерии у автора — тайна.avost
17.03.2017 16:56-1ПМ в компаниях может быть значительно выше «нижнего» звена, в зависимости от проекта, который он реализует.
Может быть, может не быть. Вы ж пример просили. В примере — нижнее :).
Нет, у меня нет, но и автор свои критерии определения «нормальности» и «крутости» не привел.
Ну, вы дальше-то не прочли, что ли? Нет критерия, есть только компаратор. "Крутой" — выше "нормального" и всё. Этого достаточно в данном случае.
Опять-таки, какие критерии у автора — тайна.
Ну, в рамках описанного, эта информация не даст ничего нового. Зачем её знать?
habradante
17.03.2017 17:35+1"«Крутой» — выше «нормального» и всё. Этого достаточно в данном случае."
Этого не достаточно, т.к. непонятно о чем автор говорит, по каким критериям связывать упомянутых автором разработчиков, с разработчиками, которых представляют себе читатели.
С тем же успехом, можно было, крутых и нормальных заменить на «плюк» и «пляк», и сказать, что «пляк» круче, чем «плюк». В теории понятно, но с какими объектами связывать в реальности — не ясно.avost
17.03.2017 23:37Этого не достаточно, т.к. непонятно о чем автор говорит, по каким критериям связывать упомянутых автором разработчиков, с разработчиками, которых представляют себе читатели.
Вы сами сказали, что у вас нет критериев абсолютной оценки, но при этом требуете её у других. Занятный случай.
Я думаю, что вы придуриваетесь, но могу, в принципе, и рассказать как, если вы и в самом деле тупите.
Слово "нормальный" в русском языке имеет коннотацию "близкий к среднему уровню", слово "крутой" — коннотацию "близкий к верхнему уровню. Дальше совсем просто. Читатель ранжирует программистов своего круга и тех, кто у верхнего края сопоставляет с крутыми, а тех, кто в серединке — с нормальными. Абсолютные величины здесь абсолютно не важны. Мне странно, что приходится объяснять настолько простые вещи.
С тем же успехом, можно было, крутых и нормальных заменить на «плюк» и «пляк», и сказать, что «пляк» круче, чем «плюк».
Да, разумеется. Если идти ещё дальше, то там в глубине обнаружится вообще формальная арифметика с набором правил вывода, но данная задача не требует такого уровня абстракции.
В теории понятно, но с какими объектами связывать в реальности — не ясно.
Я описал интерпретацию. Как у всякой формальной системы, она не единственная ;).
habradante
18.03.2017 01:13Где я требовал абсолютную оценку? Я лишь хотел чтобы автор описал свое понимание.
Ваш дальнейший… текст… я даже комментировать не хочу. Если для вас понятие среднего это величина, которая одинаково воспринимается всеми остальными, то вы живете в каком-то очень изолированном мире.
Повторю специально для вас, с разжевыванием, постарайтесь читать текст медленно. Автор описал случай, который может восприниматься как «наймите команду студентов, вместо школьников, потому что студенты круче», а может как «наймите команду профессионалов с опытом больше 20 лет, вместо среднечков с опытом 10 лет». Чувствуете разницу? Переложите на свое восприятие и попробуйте понять что же на самом деле имел в виду автор, говоря что «крутые круче средненьких».avost
18.03.2017 13:08Где я требовал абсолютную оценку? Я лишь хотел чтобы автор описал свое понимание.
Ваш дальнейший… текст… я даже комментировать не хочу. Если для вас понятие среднего это величина, которая одинаково воспринимается всеми остальнымиНу, вы даёте. Сначала отнекиваетесь от абсолютной оценки, а потом про неё же опять шарманку заводите. "одинаково воспринимается" — это и есть абсолютная оценка. И, нет, это только для вас так. Для меня ровно наоборот. Среднее в моей выборке не равно среднему в вашей. А я вам три раза пытался объяснить, что абсолютная оценка в данной задаче не требуется. Давайте ещё раз — большая стрелка на 12, маленькая на 6… Система оценок выстраивается отдельно для каждого отдельно взятого множества. Между разными множествами нет параллелей, они не нужны. Да, при этом на множестве работников условного гугла их "нормальные" будут скорее всего где-то за горизонтом крутизны на множестве работников средней уеб-студии. Но в этом нет проблемы. Каждый читатель строит свои множества и свои распределения. Он работает со своими множествами, он их знает, он их понимает. Чужие ему совершенно бесполезны.
Слушайте, ну, правда, где вы учились, что не можете представить работу с абстрактными множествами над которыми только операция сравнения задана?
Автор описал случай, который может восприниматься как «наймите команду студентов, вместо школьников, потому что студенты круче»,
Да, именно так. Если у вас в распоряжении только школьники и студенты, или возможность нанять только школьников и студентов, то какой смысл вам советовать нанять Линуса Торвальдса? Вы просто не поймёте в чём тут смысл. Или скажете — блин, не могу нанять Торвальдса, значит всё пропало. Но нахрена вам Торвальдс, если для решения вашей проблемы вам достаточно поменять школьнака на студента?
Переложите на свое восприятие и попробуйте понять что же на самом деле имел в виду автор, говоря что «крутые круче средненьких».
Можно обьяснить что два плюс два будет четыре, считая окурки, а можно, считая космические корабли. И второй вариант ни чем не круче первого. Результат-то одинаков.
RegisterWindowClassExA
16.03.2017 18:27-1Отличный коммент. Командой я не руководил. Статья родилась как ответ на виденное в жизни… На попытки некоторых товарищей собрать команду лоботрясов, которые должны сделать сложный проект. При этом системного архитектора там не было.
Все Ваши замечания очень годные. За исключением пары — про совещания. Имеется в виду не совещание с коллегами, а совещание по административной части. Болтовня в чайной часто перерастает в техническое совещание. Против технических совещаний я ничего не имею.
У Вас, судя по всему, более позитивный опыт в работе. У меня не так.
sbnur
16.03.2017 15:21Просто вопрос — что стоит за изложенными принципами:
— опыт работы разработчиком?
— опыт работы руководителем?
— опыт работы разработчиком и руководителем в разные последовательные периоды времени?
Comlan
16.03.2017 15:26Есть прокол в правиле №8:
Начальник, в основном, нужен для контроля и обратной связи. Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.
Руководитель — это прежде всего ответственность. Супер программист отвечает за свою работу, а руководитель отвечает за работу нескольких супер программистов. За ответственность нужно платить. Вот как раз найти опытного программиста/конструктора легче, чем ответственного опытного руководителя.
В остальном хорошо.Areso
16.03.2017 15:56Возьмем обычный средний город. Не долину, не Москву или не город-миллионник в РФ. А, скажем, город в 500к населения.
Предположим, половина этого населения работает, в то время как вторая — это пенсионеры, дети, студенты и люди, живущие на не свои или на нетрудовые доходы. 250к.
Предположим, что у половины работающего населения есть начальники. 125к
Предположим, что один руководитель нижнего звена обеспечивает роботоспособность 20 подчиненных. 6 250 руководителей.
Предположим, что половина из них бездари, горлопаны и люди, любящие издеваться над другими людьми. Вторая половина — плюс-минус адекватные люди (т.н. «нормальные»). 3 125 руководителей.
Внимание вопрос: как много опытных и более-менее нормальных программистов по популярному языку, возьмем 1С (упаси боже), вы найдете в городе с населением в 500к?
P.S.: опытный руководитель умеет делать крайним не себя, а кого-то другого. У опытного руководителя скорее всего были в практике и были провалы. Скажет Вася-разработчик виноват, его и уволят (ну или премии лишат, если это все-таки нужный сотрудник).Comlan
16.03.2017 16:04Вы упорно не хотите замечать в моей реплике слово «ответственный».
Я утверждаю, что ответственный руководитель априори должен получать больше ответственного подчинённого программиста. За лидерские качества, хранение секретов, ответственность за людей, человек-лидер должен получать больше любого гения программиста.
P.S. Я живу в Кирове ( 500k — как раз ваш пример) и к нам в очередь стоят программисты 1С, чтобы обслужить нашу деятельность.Areso
16.03.2017 16:15+1Гениев априори меньше, чем людей, которые в состоянии проконтролировать нормальные управленческие и хозяйственные процессы (приход-уход с работы, отпуска-больничные, постановку-выполнение задач, написание документации, закупку материалов и ОС). Грубо говоря, для ответственного управления подходит каждый двадцатый, ладно, пусть каждый сотый человек, а гении встречаются чуточку реже. Ответственность за людей в производстве кода? Это какая-то смешная ответственность, расскажите про неё тем, кто ходит под уголовной статьей, выпуская людей в цех или в шахту. Секреты хранить должны все уровни, толку от того, что начальник молчит как красный партизан, а подчиненные болтают на каждом углу, как солдаты в питейном заведении?)
К тому же, речь идет про руководителей нижнего звена, понятно, что от руководителей уровня предприятия требуются уже немного другие навыки и таланты.
Так что хороший руководитель нижнего уровня, конечно, ценен, но не ценнее гения.Comlan
16.03.2017 16:33В этом и вся беда нашего подхода к делу. До тех пор, пока мы считаем, что руководитель это тот, кто контролирует:
приход-уход с работы, отпуска-больничные, постановку-выполнение задач, написание документации, закупку материалов и ОС
мы будем путаться в определениях. Ведь вы говорите здесь не об управленцах, но о контролирующих органах. Всё это должно быть автоматизировано и регламентировано. Если очень кратко, управленец это тот, кто заряжает и качает команду. Это и есть самая большая ответственность (вместе с уголовной),
Но вы правы, гении встречаются редко и обычно им руководители не нужны.
Я выпускаю людей в цех.Areso
16.03.2017 16:44Если у вас не стартап а-ля SpaceX, зачем вам «заряжать» и «качать»? Но ладно, я согласен, руководителям верхнего звена всё же надо обладать и харизмой и виденьем даже в условно типовом бизнесе.
Но зачем это уметь делать начальнику абсолютно каждого уровня, каждого подразделения: «заряжать» и «качать»? Вы представляете себе начальника АХО, который с утра заряжает и раскачивает персонал? Или цехового мастера? Или главного бухгалтера?.. Нет, я конечно понимаю, что бывают сложные периоды (например, внедрения нового инструментария, перехода на другой техпроцесс, авралы, срочные заказы), когда нужно подчинных мотивировать работать производительнее, чем обычно, потому что из-за изменных (отличных от нормальных) условий выросла нагрузка, но в целом?
…
Если вы несете реальную ответственность, то я согласен, что вы будете получать больше даже очень талантливого рабочего, потому что если ему сбодуна однажды отфигачит пальцы, а вы его выпустили с «выхлопом» в цех — попадёте именно вы.Comlan
16.03.2017 16:58Если у вас не стартап а-ля SpaceX, зачем вам «заряжать» и «качать»?
А в чём принципиальная разница между всеми проектами мира если смотреть с позиции персонала? Ответственность врача из международной клиники, такая же как и у сельского лекаря.
Но зачем это уметь делать начальнику абсолютно каждого уровня
А как вы хотели? Как ваша харизма и виденье дойдёт до самого низа, если на одной из горизонтали она остановиться на безразличном ко всему мастере цеха. В чём тогда будет ваша ценность?Areso
16.03.2017 17:27Есть разница. Смотрите, предположим вы стартап и берете деньги у инвесторов или у людей, по факту, за еще несуществующий товар. Вы продаете им идею: ракеты будут летать по нескольку раз и это будет дешево. В вашу идею вкладываются. Есть ULA, есть Роскосмос, которые смеются над вами и работают по старинке. У них полувековая традиция, у них оборудование, специалисты. У вас — лишь идея и, возможно, некоторые наработки. И вы должны за предоплаченные деньги, желательно в срок, её реализовать. Реализовали — вы молодец, вы сдвинули парадигму. Не реализовали — следующий визионер столкнется с равнодушием инвесторов или частных людей. Они скажут «мы уже слышали это, и это плохо кончилось» и не дадут денег.
У международной клиники есть бренд. У её клиентов есть выбор. У сельского лекаря нет конкурентов, независимо от его компетентности.
Ваша харизма должна зарядить изначально пофигистичного мастера, чтобы и он чуточку внимательнее относился к своим обязанностям. Или, если у вас совсем небольшое предприятие, вы сами зарядить все предприятие, если на то есть отдельный повод. Тут же как — люди смотрят на самый верх предприятия и в общем случае подмечают, что да как.
А если мастер цеха не заряжается от своего визионера, то его нужно вовремя сменить, на более устремленного человека.
Я к чему клоню — визионер наверху это хорошо, но в уже отлаженных коллективах и производствах, это как кофе. Выпей чашечку — почувствуешь прилив сил. Подсядешь на кофеин — кружки эспрессо с перерывом в 2 часа будут давать бодрости на 30 минут, и хорошо если вообще давать. А пить надо. Пьешь и пьешь. А останавливаешься — вообще всё плохо.Comlan
16.03.2017 17:49Вы продаете им идею: ракеты будут летать по нескольку раз и это будет дешево. В вашу идею вкладываются. Есть ULA, есть Роскосмос, которые смеются над вами и работают по старинке
Я не вижу здесь ничего такого, что идёт в разрез с моими убеждениями. Просто нет в РосКосмосе русских Илонов. Нет у нас таких людей. Нет заряженности на успех, открытия. Читали последние новости про YotaPhone? Мы всегда пытаемся догонять. И смеёмся над теми, кто хочет покорить Марс.
У международной клиники есть бренд. У её клиентов есть выбор. У сельского лекаря нет конкурентов, независимо от его компетентности.
Жизнь (как противопоставление смерти) тракториста из Простоквашино и жизнь бизнесмена из Лондона равноценны для вселенной.
Ваша харизма должна зарядить изначально пофигистичного мастера,
Я об этом же. Но если между нами есть ещё начальник цеха, то я буду действовать через него. А он уже на мастера. Именно так действует правильный настрой на работу.
А останавливаешься — вообще всё плохо
А вот нельзя останавливаться (я про работу)! Сам кофе не пью, поэтому не могу провести параллель.
Будущее за неравнодушными, за людьми-зарядками!
y90a19
24.03.2017 15:24А как вы хотели? Как ваша харизма и виденье дойдёт до самого низа, если на одной из горизонтали она остановиться на безразличном ко всему мастере цеха. В чём тогда будет ваша ценность?
Кажется я понял. Бывают начальники, которые думают что если он не будет дергать подчиненных и спрашивать отчеты на каждую минуту рабочего времени, то подчиненные будут лазать по деревьям и спать.Comlan
24.03.2017 15:31Бывают начальники...
Видимо бывают. У каждого свой стиль управления и свой стиль подчинения. На каждого самодура находятся те, кто спит на деревьях.
Я только не понял, как это относится к моей мысли о создании сплочённой команды.y90a19
24.03.2017 15:47Приведите пример, как вы «заряжаете» команду, как сплачиваете.
Думаю что это на уровне дерганий, совещаний, отчетов и натужных попыток убедить работать овертаймComlan
24.03.2017 16:29Приведите пример, как вы «заряжаете» команду, как сплачиваете.
Способов очень много. Все они очень просты и описаны в книгах. Из моего опыта, самые действенные:
1. Собственное и искреннее чувство в успехе при реализации любого проекта. Это неминуемо передаётся всем остальным
2. Подача собственного примера. Например, я никогда не опаздываю на работу. И когда утром все на местах, когда все ориентируются на тебя — это безумно здорово. Или когда мои коллеги не могут решить задачу, садишься с ними и как в школе говоришь — «Ну что, давайте вместе раскрутим этот клубок».
3. Объявление нобелевской премии (куда без денег?). За реализацию любого проекта всегда объявляю премию. За решение задачи (у нас в основном технические), которую я сам не могу решить или решили без моей помощи — нобелевская (очень большая) премия.
4. Постоянная, скрытая, ненавязчивая, словесная пропаганда командного духа. Бежишь по предприятию и делаешь точные инъекции боевого духа сотрудникам, каждому индивидуально подбирая свою дозу.
Думаю что это на уровне дерганий, совещаний,
У нас один раз, по пятницам.
натужных попыток убедить работать овертайм
Вообще это запрещаю. Лень и временнЫе рамки — двигатель прогресса. В таких условиях на свет появляются очень хорошие технические решения.
У нас производственное предприятие. Не знаю как это можно всё сопоставить с IT компаниями. Но мне кажется, что природа человека во всех компаниях одинакова.
RegisterWindowClassExA
16.03.2017 18:44-11С-ники это не совсем те программисты, о которых идёт речь.
Хороший инженер часто ответственнее начальника. Т.к. он может влиять на ситуацию и болеет за то дело, которое делает. Руководитель тоже болеет, но сделать ничего не может.
dgstudio
16.03.2017 15:32-4Первое правило — хренотень. Руководитель должен быть лидером, понимать устройство рынка, интересы бизнеса, потребности потребителей. Должен быть коммуникабельным, экстравертом, немного психологом, чтобы объединять вокруг себя умных людей и вести их в нужном направлении. Должен постоянно коммуницировать с «гуманитарными» сотрудниками (отделом продаж, отделом маркетинга и т.д.)
И вы хотите, чтоб он ещё и код писал? Да щас, блин.
Второе правило тоже хренотень. Даже лень объяснять почему.wladyspb
16.03.2017 16:46+2А почему нет? Он не должен писать код — он должен понимать, как пишется код. Как ни странно, у меня уже на второй работе технически подкованное руководство, вплоть до директора который тоже понимает достаточно много в используемых инструментах.
avost
16.03.2017 18:12+2Вчера "руководил" общественной баней, сегодня "руководит" командой разработчиков? Да, в совке так и было. Ну, и вы помните к чему это привело...
mad_nazgul
17.03.2017 07:12Ну как бы примеры есть.
Вчера расстреливал врагов народа, сегодня испытал атомную бомбу <:o)
Иметь опыт разработки для руководителя разработчика желательно, но по моему не обязательно.
Главное, чтобы понимал, что делают программисты.
А этого можно добиться не имея практических навыков.zip_zero
17.03.2017 07:58Расскажите, как?
Я уверен, что без практики можно добиться иллюзии понимания, но не самого понимания.mad_nazgul
17.03.2017 12:17Пример атомный проект СССР и США.
Где возглавляли/управляли те у кого не всегда был опыт научных разработок и создание атомной промышленности :-)
Тут дело все в делегировании и кадровой политике.
Хороший руководитель найдет тех, кто может решать поставленные задачи и обеспечит им условия для работы.RegisterWindowClassExA
18.03.2017 13:25Обратите внимание, цитата из первого правила: «Я знал немало руководителей, которые полностью перекладывали технические вопросы на подчинённых, восхищались людьми, умеющими делать технику, и задавали только два вопроса: «Когда будет готово?» и «Что необходимо для работы?». Это отличный стиль руководства для неспециалиста. Подводный камень здесь только один — кадровая политика. Ошибка в кадровой политике может вылиться в срыв проекта и потерю должности. Если с кадрами повезло, то остаётся лишь обеспечить их работу. О том, как её обеспечивать — читайте следующие правила.»
DeBovuar
16.03.2017 15:32+1Автор, видимо, отлично разбирается в разработке, но слабо разбирается в руководителях (как минимум хороших и плохих). Аргументирую вывод: распространенная ошибка в том, что руководитель тот, кто следит/контролирует подчиненных. Функция контроля самая очевидная и видимо поэтому воспринимается главной. В то время как это лишь небольшая часть и возникает она как следствие. Вспомню пример Генри Форда, который проверил руководителей на "хороших vs плохих" посредством их отсутствия. Смог руководитель грамотно все организовать и работа шла хорошо и слаженно — руководитель хороший. Если же все дела валились у сотрудников из рук, значит, без своего руководителя они ни на что не годятся и виноват в этом, конечно, только сам руководитель.
Areso
16.03.2017 16:06+1Насчет шестого правила не согласен. Я бы его разделил на две части. Люди (и специалисты) бывают разные. У нас в отделе есть разработчик, который стоит как минимум двух других, а то и трёх. Быстро работает, быстро учится, не боится сложных задач. Умеет в алгоритмы.
Но количество ошибок велико. Как правило, довольно простых. И возникают они, как раз, из-за фантастической скорости разработки. А затереть чужой обновленный код из своей старой ветки — это вообще едва ли не через день. Да, кто-то скажет, система контроля версий и т.д., но учитывая реальность (где используются лишь встроенные средства для мержа, а все, что снаружи а-ля Гит/Меркуриал и прочее видит лишь блобы), такое случается. И чаще, чем хотелось бы. Ну и накатывать на живую. Каждый раз, когда я вижу, как на живой продакшен накатывают без его остановки обновления и не делая бэкапы, у меня аж сердце схватывает. Т.е. кто-то перестрахуется лишний раз и потеряет время, а кто-то сразу в прод.
Tishka17
16.03.2017 19:26В книжке, на которую ссылается статья, было несколько "пород котов". Штук пять, если не больше.
fastwit
16.03.2017 16:19+2Вот поуправляете командой, перечитаете свой пост и расскажите. Если убрать поясняющий правила текст, то правила ни на что не годятся и даже противоречат современным практикам управления разработкой. То есть правила вам сформулировать не удалось. Поясняющие тексты очень частные и порой, как мне показалось, даже притянутые. Словно, это все опыт одной единственной команды на одном единственном проекте. По сему обобщение и не удалось. Для начала попробуйте существующие гибкие методологии управления разработкой, там все уже обобщено и в большинстве случаев прекрасно подходит любой команде. И вот только когда вы столкнетесь с тем, что ваша команда сильно уникальна и аджайл не работает — вот тогда ищите другой способ. И это будут не набор правил, а ваш собственный опыт.
И да, как же пасти котов и причем они тут вообще?fastwit
16.03.2017 18:14По пунктам:
1. Противоречит по крайней мере моему личному опыту. Что я видел на множестве проектов — лучшие руководители, как правило, не разработчики. Но тем, кто вышел из разработчиков, всегда очень трудно перешагнуть через свое «разработческое мылшение» и собственно хорошими становятся те, кому это удается.
2. С одной стороны правило «капитанское». Заставлять разработчика переключаться на мытье полов — это плохо и неэффективно. Но команда должна быть объединена общей целью и задачи — это шаги к ее достижению. Если какая-либо даже не техническая задача нужна, то ее кто-то должен сделать. Пусть это не написание кода, но если в ней есть потребность это не прокрастинация. Ну и переключение — это как раз-таки не проблема для разработчиков — это часть работы и иногда очень полезно.
3. Иерархия организационной структуры никак не поможет в устранении сложности. Самые лучшие продукты делались в условиях отсутствия иерархии, субординации и бюрократии. Системный архитектор — это самая непонятная роль. Я даже не знаю как вакансию написать на поиск такого человека. И чем он будет сильно лучше опытного разработчика, который уже есть в моей команде?
4. Не давайте уборщице разрабатывать модуль шифрования в вашем приложении — это вы хотели донести? Или для написания циклов for у нас есть отдельные узкие специалисты для JavaScript и для C — так? Давать фронтендеру проектировать эл. схему — это странно, если есть специалист, но если больше некому, то он разберется — это особенность разработчиков, они всегда разберутся. Ну или наймете уже наконец спеца. Я понял, что по правилу 4 ничего не понял :(
5. Это еще один «капитанский» тезис. Но. Как раз проблемой руководителей вышедших из разработчиков является высокая толерантность к ошибкам. Ошибки в программировании — это ошибки, ну даже слово само за себя говорит. Не надо их делать чем-то другим. Задача каждого программиста научиться делать их как можно меньше. Задача команды выстроить процесс так, чтобы их как можно меньше проскакивало в конечный продукт. А искать виноватых вместо искоренения причин — это плохая практика независимо от отрасли.
6. Из вашего текста только понятно, что есть особенные специалисты, которые маскируют свои ошибки лучше. Если вы будете полагаться на ключевых специалистов, то устанете закрывать кадровые дыры. Хорошие специалисты меняют место работы достаточно часто. Опять же, тут важен правильный процесс и его слабая связанность с конкретными личностями разработчиков, а также knowledge sharing и коллективная ответственность.
7. Вы удивитесь, но разработчик может работать и на совещании. Придумывать алгоритм, пока начальство несет бред. А может и вникать в тонкости требований. И точно также может просто расслабляться, когда пьет чай. И вообще не думать о работе.
8. Под рыночными принципами вы имеете в виду что? Если вы выбрали в качестве организационной структуры иерархию/субординацию, то это скорее всего связано с делегированием ответственности. В такой структуре, если специалист получает больше вас, то он важнее вас, его вклад больше и ответственности больше. И скорее всего эффективнее будет заменить вас на него, ибо вы со своими задачами не справляетесь.
9. ТК РФ хоть и слабо, но защищает работников от некомпетентности начальства. Разработчиков, злоупотребляющих ТК в разы меньше, чем начальников. Даже плохенький разработчик найдет себе другую работу, нет смысла сильно держаться, когда тебя не хотят. Это не сговорчивость — это здравый смысл.RegisterWindowClassExA
18.03.2017 12:55По шестому правилу с Вашей критикой согласен.
Что касается остальных — не согласен. Мне, в свою очередь, кажется, что Вы недооцениваете такое понятие как архитектура проекта. Возможно, недопонимаете это понятие. Отсюда недопонимание роли архитектора.
На мой взгляд, архитектор — это человек, который определяет, какие классы/объекты будут в программе, какие у них методы, какие действия выполняются объектами с помощью этих методов. Он объясняет сотрудникам, какие классы нужны, как он их объединит для решения задачи. После этого те, кто понял архитектуру, делают свои предложения по архитектуре, кто не понял — идут реализовывать свои ТЗ.
Тут, конечно, возможно недопонимание. В сложном проекте могут быть десятки и даже сотни подсистем, и все они должны слаженно работать. Для простых проектов архитектура часто очевидна и архитектор почти не нужен.
Отчасти Вы правы — статья написана в результате работы в одной команде, и под впечатлением того, как делать не надо. Советы написаны по принципу «от противного». В моей команде пытались уравнивать «звёздного» программиста с просто хорошими, отсюда возникло правило 6. Безусловно, категоричность не доведёт до добра, но я начинаю понимать японцев, которые обижаются, если идущего, скажем, в отдел кадров сотрудника попросить захватить с собой документ для отдела кадров — для этого есть курьер. Конечно, ключевой показатель работы — это продукт, и для его достижения правила нужно иногда нарушать. Но нельзя строить работу так, чтобы нарушение правил было нормой. Ну и, конечно, у каждого правила есть разумные границы применения.
Статья, в основном, адресована тем, кто путает «ответственность, лидерские качества и умение повести за собой людей» с наличием прямых рук для создания продукта. Творческим людям нужные творческие задачи и творческая мотивация, тогда они создадут классный продукт. «Зажечь» их может только творческий человек, азартный опытный разработчик. Он, правда, не должен навязывать исполнителям свои методы решения задачи. Его задача — архитектура, плюс некоторые предложения по реализации. Если исполнитель хочет по-другому, пусть делает по-другому. Хорошая архитектура — это когда подсистему можно переписать с нуля, использовав только ТЗ, заменить её в проекте, и проект продолжит работу как и раньше.fastwit
20.03.2017 14:02У нас с вами разные взгляды на архитектуру и архитекторов, очевидно. Я не хочу сказать, что мой взгляд правильный или ваш не правильный. В индустрии программных проектов много путаницы с ролями и ответственностями из-за того, что проекты разные. Очень разные. Иногда приходят люди, которые были архитекторами в веб-студиях и они словно из другой реальности по отношению к архитектуре ERP систем. Я не умаляю их возможностей, я, лишь, говорю о том, что опыт очень разный.
Задача архитектора в том, чтобы система жила и адекватно менялась в ответ на внешние раздражители в виде новых требований. Красота кода, объектной модели, выбранной СУБД — это инструменты и решения, которые архитектор использует для выполнения своей задачи. Есть порочная практика сравнивать архитектора программных систем с архитектором мостов и зданий. В строительстве все требования и параметры результата известны заранее. Местность, почва, воздух, водоемы, скорости ветров, перепады температур, ураганы, тайфуны и так далее — все это учитывается в начале и закладывается в архитектуру. Программные же проекты начинаются в условиях неполных требований, а потом живут в условиях меняющихся реалий. Если обратиться к аналогии, то вы начинаете проектировать асфальтированную тропинку в лесу, потом встречаетесь с болотом, потом со скалой, потом выходите на берег и понимаете что нужен мост. Далее достраиваете мост, чтобы добавить велосипедную дорожку, потом движение автомобилей, внезапно появляется железная дорога, заправка, придорожное кафе на мосту с официантками и столом для настольных игр… И так далее, и тому подобное.
Хорошая архитектура — это не столько возможность переписать отдельный кусок с нуля, сколько возможность вносить изменения в систему с минимальными рисками и издержками в любое время. А не так, что за первый год написали систему с красивой архитектурой, а потом понеслась…
a_a_j
16.03.2017 18:17Из этой статьи я узнал, что работаю не только программистом, но еще и архитектором, дизайнером и менеджером, попутно переключаясь с одной задачи на другую в течении дня. Где-то в этой жизни я повернул не туда. Стоит скинуть эту статью своему руководству.
RegisterWindowClassExA
16.03.2017 18:18-1Если Вы всё успеваете, возможно, ситуация нормальная. Либо сложность проекта небольшая, либо Вы отличный спец! :)
Contriver
16.03.2017 18:32Это точно не для России
если им прямо сказать: «Вы нам не подходите… не вопрос минимум 1 оклад, не хотите то 100500 причин начиная от косяков в трудовом договоре до условий труда, аттестации рабочего места, охраны труда и пр. он лайн обращение в трудовую инспекцию и проверки задолбают работодателя.Надо соответствовать названию — скот
Наказывать пасущих скотов надо рублём
M_AJ
16.03.2017 18:35Девятое правило очень интересное. Особенно интересно, как же заманить в свою компанию "более лучших", и как определить, что ты, в пылу поисков, не решил уволить лучших из тех, кто в принципе может согласиться в ней работать.
mad_nazgul
17.03.2017 07:17Девятое правило, это типичная отрицательная спираль развития.
Вместо того, чтобы привлекать хороших специалистов (условиями работы, проектами и т.д.), отсеивают «плохих».
Большой простор для «подковерных игр» и создания «серпентария».
:-)
Diman_94
18.03.2017 12:07На двух прошлых местах работы наблюдал такую тенденцию: самые лучшие работники растут быстро и либо а) в большой компании не принято так часто повышать в должности и им приходится уходить либо б) в маленькой компании нет возможности платить большую з/п и им приходится уходить. При этом работники «ниже среднего» очень держатся за свои «насиженные» места и старательно изображают деятельность (как вариант: покупают печеньки, ходят на субботники, не опаздывают и т.д.).
Видимо, автор ведет речь о борьбе с плохими работниками. Он так же упоминает что надо заменять их хорошими, но самое главное тут — как заполучить этих хороших? Я это видел только один раз на текущем месте (стартап) — разработчиков всего трое на три подсистемы, поэтому цена ошибки очень велика, и набрали лучших из тех, что нашли. Которых не нужно мотивировать дополнительно, достаточно внутренней мотивации и желания не подвести команду. Но как эту атмосферу равенства и братства сделать в команде хотя-бы в 10 человек, уже не представляю — все равно кто-то будет отставать.
lencom
16.03.2017 18:48Если разработчик сидит на совещании — он не работает.
Разработчики участвуют в оценке проектов, в подготовке технического решения (не всегда это может сделать аналитик и не всегда он есть), должны уметь доносить результаты своей работы, объяснять свои идеи — для меня, и как для разработчика, и как для руководителя, это наиболее эффективный способ. Вы просто не зовите их на все совещания.
Составить план, контролировать его выполнение. Это задачи довольно простые, и их может исполнить любой мало-мальски дисциплинированный человек.
Если бы так, то факапов со сроками и качеством было бы гораздо меньше. Помимо дисциплины необходим навык управления командой, процессом, работы с мотивацией,интуицияопыт, авторитет на основе знаний. Здорово, если всё идёт «как по маслу», и не нужно принимать сложных решений, когда что-то идёт не так — но это отрыв от реальности.
При этом вы говорите:
Поэтому потрудитесь распределить задачи качественно, чтобы избежать неприятных сюрпризов.
Это не может делать просто «любой мало-мальски дисциплинированный человек» — проверено. Вы сами себе противоречите.RegisterWindowClassExA
16.03.2017 18:58-1Спасибо за ответ. Я подразумевал, что задачи распределяет архитектор. Он же назначает сроки. Он же участвует в совещаниях, посвященных технической стороне продукта. Если совещаются по срокам, он туда не идёт. Он же назначает премии.
mad_nazgul
17.03.2017 07:22+1В ваших словах противоречие — «назначает сроки», " Если совещаются по срокам, он туда не идёт.".
Ну как бы архитектор, по вашему, ответственен за сроки.
Т.к. он их поставил и это его зона ответственности.
И при этом он не идет на совещание по срокам.
Обычно на таких совещаниях (если они с заказчиками) можно «отстоять» свои сроки.RegisterWindowClassExA
18.03.2017 12:15Что значит «ответственен»? Мне непонятна эта абстракция слова «ответственен».
Ответственность — это фикция. Квалификация — это гарантия результата.
Квалифицированный сотрудник сделает задачу при нормальной ответственности. Неквалифицированный руководитель провалит проект при самой высочайшей его ответственности.
Отстаивать сроки должен представитель администрации. Который должен быть поставлен в известность о вариантах разработки. О том, сколько работы необходимо ещё выполнить. Стоит понимать, что ускорение разработки возможно только в одном случае — если перегрузить работников. Это можно делать краткосрочно, за доплату и с предоставлением последующего отдыха. За это заказчик должен доплатить. Соответственно, руководитель должен иметь представление о вариантах развития событий. Архитектор должен эти варианты ему обозначить. Какой режим и срок разработки нормальный, какой — интенсивный, какой — сверхинтенсивный, какой не реален. Если обсуждается изменение ТЗ в части возможностей продукта — тогда архитектор нужен. Если говорить про сроки — все варианты развития событий (в т.ч. вариант предоставления сырого макета с последующей доводкой) должен знать администратор.
Основной посыл статьи в том, что работа делится на две части — административную и техническую. И администратор в продукте играет почти никакую роль, лишь подбирает технические кадры. Соответственно, технари тоже должны быть от административных вопросов изолированы.
RegisterWindowClassExA
18.03.2017 13:38Ответственность это фикция уже потому, что продукт делается за фиксированное время. Независимо от ответственности. Производительность труда довольно стабильная штука. Постоянно работать по 16 часов можно недели две, потом производительность падает, и всё, приехали. Но зависимо от квалификации. Можно пару раз пойти не тем путём, сжечь все силы на переработках, а проблема будет в архитектуре. Можно выбрать удачную архитектуру и в рабочем режиме, без переработок, заполнить её функционалом. Вопрос в том, кого Вы выбрали руководителем проекта.
Опять же, сбоящая подсистема тормозит всю команду, т.к. она стопорит продукт, и архитектор вынужден участвовать в поиске ошибок. Поэтому квалифицированный кодер для проекта лучше неквалифицированного. Вопрос в том, кого Вы набрали в исполнители.
Если архитектор налажал со сроками/архитектурой/ТЗ для исполнителей, то никакая ответственность тут не поможет. Вы ведь его не расстреляете, и деньги с него не возьмёте, и что Вы хотите от него услышать на совещании? Толпа народа вызовет у него лишь желание изворачиваться, и проблема, скорее всего, будет от вас скрыта до дедлайна и после дедлайна и так далее. Лучше переговорить с ним доверительно с глазу на глаз, переговорить доверительно с другими «звёздами» и ведущими, использовав коммуникационные навыки, и уже потом без него принимать решение о дальнейших действиях — либо менять архитектора на другого ведущего спеца из команды, либо… Либо докладывать начальству о катастрофе в разработке проекта.
Mimus_spb
16.03.2017 21:54В статье отсутствует важная деталь.
Автор забыл объяснить зачем руководителю соблюдать все придуманные им правила.zip_zero
17.03.2017 08:00И правильно. Это статья, а не пропаганда.
Соблюдать или нет — каждый решает сам, исходя из своих знаний и опыта.
RegisterWindowClassExA
18.03.2017 12:21+1Если руководитель хочет решить поставленную задачу, ему следует проанализировать предложенные правила. Правда пара комментариев получилась лучше статьи. Правила слишком бескомпромиссные. Для рутины действительно нужны обычные разработчики, они не так склонные менять место работы. В сочетании с опытом они являются хоть какой-то страховкой от кадровых катаклизмов (типа увольнения нескольких ключевых спецов, из которых я предложил собрать команду).
kiaplayer
Не совсем понял заголовок вашей статьи.
Что вы хотели этим сказать?
Lelik13a
Сдаётся мне, что это отсылка к книге «как пасти котов».
Draconian
Да и половина правил оттуда.
Boniface
Может автор хотел сказать, что программисты — это скот?