Что делать с этими цыплятами?
К прошлому посту про спецов в IT хорошие комменты, спасибо, друзья. Небольшая разведка по нашим региональным программерским конторам показала, что фигня может происходить в рамках любой компании – большой и маленькой, изначально говёной или хвалёной всеми (некоторое время), и приступы интенсивной ротации кадров беспокоят отрасль вне зависимости от качества самой компании. Доходят слухи о массовом бегстве программеров из нескольких контор, которые нам периодически ставили в пример (считалось. что недостижимый), и мы растём, если бы можно было как-то определить средневзвешенный индекс, средний уровень всех наших спецов. Но всё равно – как будто по кругу, проблемы, актуальные год назад и, казалось бы, решённые, возвращаются и морочат голову.
Все знают, как не просто бывает в командной работе договориться дизайнеру и программеру. И вот, после долгих месяцев трений (до повышенного тона и выяснений, кто виноват) и программер разобрался, где какой скрипт-код как написать, для того, чтобы реализовать нарисованное, и дизайнер приноровился, что рисовать, для того, чтобы это реально было внедрить, и тут – опаньки! – очередной программер исчезает из поля зрения в поисках лучшей жизни. Приводят следующего – и опять встречаем ту же упёртость – это реализовать нельзя!
Чётко видно два подхода. Одни говорят – я в самом деле не знаю, как это сделать, и не встречал, как это кто-то делал бы. Но попробую разобраться. И идёт разбираться, кто-то быстрее, кто-то медленнее, но, в конечном итоге, всё сростается и основная здесь проблема – получить новичку время на исследование-обучение + договориться с дизайнером, что и как они будут делать. Вторые дизайнеров за авторитет не почитают ни в каком приближении, и если эти “художники” добавляют ему каких-то проблем, просто отшивают их, мол, нереализуемо. А заказчики – они что, они качество кода оценивать не будут, для них всё качество заключается в работает/не работает, зато на красивые фантики (заставочки, кнопочки, иконочки) покупаются моментально. Если в компании чрезмерно уделяется внимание внешнему виду в ущерб логике и коду – это плохой метод, потому что в конечном итоге бесперспективный. Но если есть здоровое понимание важности грамотного и красивого интерфейса для утверждения (и дальшейшего развития-совершенствования) проекта, а программер в силу недостаточности опыта не догоняет принятую в качестве стандарта модель – начинается конфликт. В самом деле. Дизайнер, вместо того, чтобы продумывать форму и сценарии показа форм, отношения цветов и отрисованные элементы становится дурацкой пешкой, которая бегает между программером и PM, торгуясь – будем мы делать ТАКОЙ интерфейс или нет (потому что именно ЭТОТ программер, в отличие от ПРЕДЫДУЩЕГО, пока не может быстро реализовать задуманное с графикой). Фигня какая-то.
Капризы со сценариями форм вообще удивляют. Ок, хорошо, сделали прогу, есть у неё триальная версия, возможность зарегестрироваться по ключу и возможность купить напрямую. Есть интерфейсная форма в триальной версии, в которой присутствуют кнопки “Buy” и “Register”. При клике на “Register” открывается модальное окно (т.е. поверх предыдущего, и предыдущее недоступно, пока не будет закрыто верхнее), в котором можно ввести ключ и + опять же кнопки – “Buy”, “Try”, “Cancel”, “Register”, и определён сценарий, что можно ввести ключ, нажать “Register” и зарегестрировать прогу. При клике на “Buy”, ясный пень, уйти на оплату. Для двух оставшихся реализовали следующий сценарий: при клике на “Try” предполагается, что юзер передумал вводить ключ, закрывается модальное и становится доступным предыдущее из триальной версии. При клике на “Cancel” – вообще сюрприз, закрывается вся программа! Спрашиваю – с чего вдруг? Где они вообще встречали такой удивительный по юзабельности интерфейс? Пользователь видит полноценное окно поверх основного – с кэпшином, крестиком (на закрытие окна), функциональными элементами и предполагает, что при нажатии на “Cancel” закроет именно это окно, а не все открытые, не всю прогу целиком. Всмысле нормальный пользователь (а ЦА проги – это как раз не гики оторванные, а среднеобученный юзер, который, к тому же, пользует программу с целью РАЗВЛЕЧЕНИЯ). Программер же в ответ начинает спорить, объясняя правильность именно своего сценария тем, что это же МОДАЛЬНОЕ ОКНО! Здрасьти, говорю, а где ты написал юзеру, что это модальное окно и по Cancel`у закроется и оно, и основное? Где ты вообще оставил обычному юзеру мануал по поводу того, что такое модальное окно и особенности управления модальными окнами?
В общем не важно, через PM, ессно, переразобрали сценарий по формам и кнопкам, на вопрос программера “а как я буду делать вот это…” – отправили всё-таки разбираться, сейчас интерфейс (последнюю версию ещё не видела) должен стать более естественным и привычным. А вот проблему поставить на виндовую форму нестандартную кнопочку (набор картинок, имитирующих поведение кнопки – с кликом, с фокусом, с disable и т.д.) – ещё нет, ещё не умеем, опять. Опять. Блин. Уже предчувствую, как будет колбасить нашего заказчика – он до сих пор считает, что знания это что-то вещественное, принадлежащее компании в целом, и если какая-то технология отработана, то при уходе носителя технологии следующий новичёк прям за неделю всё освоит и реализует как и ожидал заказчик. Я даже знаю, чуть ли не дословно, что он скажет.
С верстальщиками (как-то после нового года все эти недопрофессиональные проблемы приобрели массовый характер) то же самое – опять проблемы между рисующим дизайнером и техническим. Опять несоответствие отрисованного эскиза отвёрстанному сайту, опять отговорки – дизайнер нереализуемую фигню нарисовал (мол, эта фичечка того не стоит, чтобы из-за неё ТАК усложнять код) – и снова до конфликтов. Разбираем – что ТОГО стоит, чем можно пожертвовать и где верстальщик проявил элементарную лень разбираться с макетом, чуть более сложным, чем предыдущие. И, кажется, это всё решаемые вещи, там подучился, там разузнал, там – договорился, но как-то очень явно именно последние посленовогодние дни давит проблема недостаточности знаний/опыта у новичков, проблема постоянного выяснения отношений и конфликтов именно на почве можно/нельзя реализовать. А ведь ещё месяц-полгода назад уж было решили, что вышли на уровень взаимопонимания и сделать можно всё – было бы желание (и,может, время) и договориться можно обо всём.
Но к вопросу о характерах спецов и к вопросу о том, кто как подходит для командной работы – трудно работать, когда один из команды авторитарно грузит тем, что “это сделать нельзя или можно, но нерационально сложно”, когда на торговлю и договорённости тратится излишне много времени. С другой стороны практика показывает, что программеры с подобным характером чаще берут на себя ответственность за свой код, проявляют инициативу и продвигают нестандартные решения. Может, и легче работать, когда программер любую поставленную задачу дотошно и смиренно ковыряет (в большинстве подобных случаев – заваливая сроки), пассивно относится к любой постановке задачи, не вникая в суть. Да, ясно, что через время происходит какая-то рокировка в командах, кто-то сползает до кодера простых модулей – с 10 до 19, кого-то ставят ведущим программером или тимлидером, но какое-то время (вот как у нас в посленовогодний движняк в кадрах) работать тяжело, дизайнеры все как-то напряжены, программеры смотрят на них волком и шушукаются (представляю, что они говорят). Верю, что пройдёт время, и можно будет увидеть талантливых программеров (или середнячков на подхвате), но сейчас они все разделяются на (извините, уважаемые) пассивных и занадто резвых. Что лучше – никогда заранее не знаешь, и только спустя год можно увидеть, что же у нас вышло. Вот из вчерашних дискуссий в прошлом посте интересный коммент:
Если спросить любого (почти) работодателя, то для него будет лучше программист, который средненько делает средние задачи, но честно делает их по 8 часов в сутки.А программист, который готов вылизывать код до блеска, и может написать программу, выводящую свой исходник на языке brainfuck — ему не нужен.
У промышленников всегда больше ценились першероны, чем арабские скакуны.
У меня есть в тему совершенно личный пример. Человек, который на одном месте долго сидеть и бездельничать физически не может, работает в конторе (не нашей) сисадмином – большая распределённая сетка, куча сервисов и все дела. Но он выбил себе свободный график – иногда сутками-неделями сидит в офисе, чего-то там сетапает, настраивает, слушать невозможно про все его офисные приключения. Потом, настроив всё и всем, может неделю не показываться и дальше – периодически на несколько часов заезжать, юзерские проблемы помогать решать. Объясняет это так: а зачем мне здесь сидеть – всё работает! И удержать невозможно было. Так же, как и заставить уйти в шесть вечера из офиса (ага, счас, это вы клиентам объясните, что у меня с 9 до 12 плановая профилактика!). Получается, что этот (и в самом деле талантливый, решающий все проблемы, не имеющий нерешаемых проблем) сисадмин – типичный арабский скакун – штучка дорогая, но малоуправляемая. Крайности, конечно, в жизни всё с менее чёткими границами, и не всегда с первого взгляда-первого рабочего дня получается узнать про новичка и предсказать его будущее. Да и у нас, конечно, всё настроется, не первый раз (увы), просто нужно переждать очередной ледниковый переходной период.
Единственная больная тема – это обучение (дотягивание до уровня) новичков тимлидерами 
это факт, это расстраивает. Рассказываешь, делишься, тратишь время и не знаешь – через три месяца с полученными знаниями потеряешь специалиста, через пол года, через год? И тема эта актуальна и для дизайнеров, и для программеров. Смотрю, что и в программерской среде у тех наших, что с таким энтузиазмом помогали новичкам ещё год назад, и даже мастерклассы какие-то устраивали – как будто руки опустились. Задатков учительских нет, повторять одно и то же долбоочередным новичкам надоело, до специально назначенных на проведение спецкурсов сотрудников наша компания пока не доросла, да и размеры компании стали заметно больше (новички, может, и подходили бы к старожилам с вопросами почаще, но те рычат, ибо если отвечать всем на все вопросы – они не смогут работать 
а кто, если не они? На их профессионализме пока всё и держится…). Так что новый год, похоже, принёс новые заботы – что делать с этими цыплятами и как перейти (помягче бы) на более… быстрое обучение сотрудников? Ну и как учить их работать в команде, нормально договариваться между собой, общаться? А то мне это третье за последнее время сообщение “я с этим работать не хочу, я лучше с этим…” мягко говоря, травмирует.
скажите, Татьяна, а у Вас в компании есть четкая вертикальная иерархия? т.е. что и в какой последовательности разрабатывается, что и в какой последовательности утверждает и что чему должно соотвествовать? если ответ “да”, тогда мне странно поведение Ваших программистов, а еще больше — поведение Ваших тимлидов. реализовать можно все, что угодно. затем программист на свою должность и посажен, чтобы реализовывать. нет не решаемых задач, другое дело, что чем сложнее задача — тем больше занимает времени ее реализация. ответ же “нереализуемо” равен ответу “не желаю делать!” и влечет за собой такие же санкции. это первое.
и второе, какие могут быть споры относительно правильности или неправильности утвержденного макета? да даже в том случае, если элементы контента прийдется делать с шириной 373 пикселя — все, макет утвержден. а значит сидим и делаем.
мне кажется, что все проблемы связаны с трудовой дисциплиной. и это в первую очередь проблемы лидов.
Антон, все всё понимают. Только у нас сейчас с виндовыми сишниками суровые проблемы, у них и лида, как такового, нет уже – есть самый перспективный и способный из всех, но в вопросах интерфейсов (скинов, и т.д.) для виндовых форм он сам не особенно разбирается. Как-то так получилось, что был большой период, когда проекты приходили в основном вебовские, вот и разбазарили виндовых программеров. О том и пишу – циклично всё. А сейчас опять много виндовых приложений пишется, а команда молодая совсем. Третий раз этот этап у нас в конторе за 2,5 года.
тогда наверное нужна какая-то Wiki в которой прописан КМБ, чтобы каждый раз не объяснять, кто здесь главный и почему от желания программиста аж ничего не зависит. ну я так бы делал.
Ах, мечты.
Да, бюрократия (прописанные роли, ответственности, подчиненность и прочее) нужны.
И как ты думаешь, что получилось, когда инициативная группа (из 5 человек) у нас написала такой документ?
Сначала его просмотрели все сотрудники отдела, потом утвердили (на уровне дирекции), а потом, через полгода — забили на него. По причине “Да мы и так договоримся, зачем нам эти документы?”.
Хотя, чаще всего договариваться не получается (особенно когда возникает вопрос — а кто, собственно, отвечает?).
Может быть, потому что эта бумага была послана снизу? И начальству было начхать? Так тогда это проблема управленческая, а не программерская. Да и обидно было — собрались, прописали, вычистили, обговорили… А потом — пшик.
Это к слову о том, почему пропадает инициатива.
а причем, прости, Wiki к построению и контролю вертикали? вертикаль она есть. а Wiki (можно набор доков, как было в Миратехе при мне, но Wiki лучше) это лишь хранилище знаний. опыт старших товарищей — чтобы не объяснять по 100 раз и КМБ (курс молодого бойца) — чтобы если начнутся качели “а кто сказал, что дизайнер главный”, перед тем как к СТО на ковер отправлять, носом в КМБ ткнуть.
теперь о “забили”, “обидно” — когда я работал на своей первой работе, мой тим лид, а потом мы вместе с ним строили команду сами. сами настривали систему контроля версий и багтрекер (при усиленном сопротивлении вышестоящего начальства. доходило до приказов все снести). сами настраивали систему автоматических билдов, тестов, репортов, выделенный сервер. все сами. и нам не было обидно, мы просто экономили свое время в будущем, расходуя его сегодня. и результат был самый радостный. тут, Саша, тоже, кто хочет — делает. а забить… а забить проще всего. и начальство всегда плохое, и проблемы всегда менеджерские.
Хорошая статья, но очень уж букв много. gzip -6
На тему “скакунов и першеронов” — так правильно. Скакун — он всегда дорог, сложно управляем и так далее… И он действительно может очень многое. (только не тягать центнеры туда-сюда, туда-сюда, туда-сюда…)
Ему простор нужен.
А насчет всех “внутрикорпоративных передряг” и прочих переходных периодов — вот тут как раз выплывает такая вещь, как “команда”. Отношения к административному делению фирмы не имеет, кстати.
Команда — она сама по себе. Это неделимая единица. И команда, после того как сформирована, обычно не меняется (за исключением очень редких случаев).
Тимлидер в данном случае — это не просто мощный программер, который может (теоретически) управлять группой человек. Это именно тот человек, к которому прислушивается данная конкретная команда. Не более того. И он может даже не быть супер-программистом или супер-дизайнером, или кем-то еще. Он просто является сердцем команды, идейным двигателем и так далее…
Некоторые фирмы, которые построены таким образом, очень даже успешно работают на рынке (как пример — Ашманов и Со Товарищи). И очень часто — многие другие, обычно — не очень большие фирмы.
Кстати, очень многие авторы говорят о создании именно такой вот команды, в которой все всех как раз понимают, знают и уважают. Но — такая команда неудобна в управлении. Потому что она, опять же, неделима. И внутрикорпоративная ротация часто и идет как раз для того, чтобы такие вот команды не образовывались.
Зачем? Элементарно. Если нет команды, то при увольнении одного сотрудника не уйдут все остальные, да и сотрудники будут посмирнее. Не будут требовать себе “работать с тем-то или с тем-то”, ну и так далее. Попытка представить человека как что-то заменяемое часто и делает человека чем-то заменяемым — человек просто меняет фирму
И тогда и выплывают все бока с “незаменимых у нас нет” — так ведь говорят, кажется?
во-первых, командное деление — прерогатива продуктовых компаний. проектоориентированные компании не имеют монолитных команд. есть пул разработчиков и пул проектов. это эффективнее. nothing personal, никакого масонского заговора, just business.
во-вторых, ни разу не видел тим лида, который был бы слабее подчиненных. разве что в аспектах. но никак в целом. все знакомые мне лиды люди с колоссальным опытом девелопменат. а успешные лиды — еще и с колоссальным опытом управления. именно это и дает им авторитет. хорощий человек — не профессия.
в-тетьих, было бы ошибкой думать, что при увольнении одного сотрудника начнется массовый исход. я пытался как-то сорвать команду полностью. я не был лидом, но разговоры подрывные вел, каюсь. никто. команда просто развалилась. даже если уходит тим лидер, не всегда уходит команда. а уж если девелопер уходит… отряд не заметил потери бойца, называется картина. это миф, нет в реальности такой единицы, как комнада. во всяком случае я не видел ни разу. это только во дворе каждый за каждого, в бизнесе каждый сам за себя.
и последнее. Татьяна, я очень извиняюсь за весь тот флейм, который я и мои увжаемые собеседники устроили в Вашем блоге. если Вам интересна дискуссия я с удовольствием продолжу обмен мнениями здесь. если нет — всем заинтересованным предлагаю свою площадку и вывешу отдельные посты по теме. в любом случае, до оглашения Вашего вердикта прекрашаю писать коментарии в этот и параллельный пост. извините, если что не так.
джентельмены, беру тайм-аут до решения хозяйки, надеюсь на понимание.
Антон, хозяйка рада вас видеть – и мне в самом деле важно ваше мнение. Вы меня хоть поддерживаете – не оставляете один на один со всеми этими проблемами (а их на самом деле ещё больше, чем признаюсь в блоге).
Так что…
Так. И по поводу вот этого последнего комментария. Не знаю писать отдельным постом или нет, но на самом деле реальная ситуация, в которой я была не только свидетелем, но и участником – именно как, благодаря авторитету (сильной харизме) тимлидера сорвалась целая полноценная команда, ушла, и даже успешно поработала некоторое немаленькое время вместе. Слухи дошли, что трое из ушедших тогда до сих пор, спустя почти 6 лет всё ещё работают вместе.
Так что… Это не миф. Но говорить о “команде” в отрыве от реального лидера я бы и в самом деле не стала.
буду рад видеть и отдельный пост тоже. что же касается описанной ситуации — я не склонен обощать. ситуации могут быть разные, и рассказы о том, как команды уходили в свободное плаванье доходили и до меня. я и вправду не видел такого, но поскольку факт имеет место быть — тогда это действительно не миф. но и возводить такое поведение в абсолют, который волнует топ-менджмент всех компаний, имеющих монолитные команды тоже я бы не стал.
если разбирать мой третий пункт ответа на составляющие, то я оспариваю следующие тезисы:
“такая команда не удобна в управлении” — полная чепуха, либо абсолютная некомпентность СТО конторы, которому по должноти положено уметь управлять разными людьми. либо еще хуже — абсолютно не правильное понимание сути управления командой. в любом случае некомпетентность топ-менеджмента.
“не будут требовать себе “работать с тем-то или с тем-то”, ну и так далее.” — просто смешно. это вольный подрядчик может себе позволить требовать себе что-то. наемный сотрудник всегда высказывает свои пожелания и соображения. иначе говорят просит. он рабочая единица, он не может чего-то требовать. по определению. в любом случае, решение о той работе, которую будет делать наемный работник принимает его наниматель. и тут выбор прост — делать и продолжать работать или честно сказать, что делать этого сотрудник не хочет, но быть готовым к увольнению.
“если нет команды, то при увольнении одного сотрудника не уйдут все остальные” — в большинстве случаев не уйдут и так. разве что дела в конторе плохо, так тут не от команды зависит, а от общей ситуации.
” да и сотрудники будут посмирнее.” — не будут. разве что это люди, еще не знающие себе цену. иными словами, еще не родился такой начальник, которому я позволю себе хамить или себя строить.
“такая команда не удобна в управлении” — полная чепуха, либо абсолютная некомпентность СТО конторы
Ну, стоит учесть, что, во-первых, при нашей системе управления, часто встречающейся во многих компаниях — когда управленцами становятся программисты, дело которых писать хорошие проекты, а не управлять людьми — таки да, полная некомпетентность. Тем более что программисты в массе своей и не стремятся учиться управлению, даже когда приходится.
Во-вторых, для управления командой нужен отдельный подход. Хороший пример — SCRUM, в котором команда как таковая вообще не управляется (является самоорганизующейся). И таких “отдельных подходов” — масса. Для каждого случая — свой.
наемный сотрудник всегда высказывает свои пожелания и соображения. иначе говорят просит
Свободный подрядчик тоже может только просить — иначе будет выбран другой подрядчик, тут все просто.
Но если вольнонаемные подрядчики это понимают, так как им часто приходится также выступать именно в роли менеджеров, то наемный работник об этом забывает. Он “не в тех сферах вращается”, и “все менеджеры козлы, нифига не понимают”.
Кроме того, есть такая штука, как трудовой договор, в котором положено указывать, кто, что и кому должен, может и так далее. Который, увы, частенько не составляется, и все пускается на самотек. (или — должностная инструкция, которую сотрудник видит только случайно).
в большинстве случаев не уйдут и так
а есть просто группа наемных работников.
Да, не уйдут. Потому что очень часто нет команды.
еще не родился такой начальник, которому я позволю себе хамить или себя строить
Да. А что будет, когда таки попытаются?
тем более что программисты в массе своей и не стремятся учиться управлению, даже когда приходится. —
по законам военного временипо не соотвествию занимаемой должности. ты чтоли работаешь там, где я думаю? Дом Быта Центральный 10й этаж?И таких “отдельных подходов” — масса. Для каждого случая — свой. — браво! именно так.
Свободный подрядчик тоже может только просить — иначе будет выбран другой подрядчик, тут все просто.
Но если вольнонаемные подрядчики это понимают, так как им часто приходится также выступать именно в роли менеджеров, то наемный работник об этом забывает. — и задача его непосредственного руководителя об этом напомнить.
Он “не в тех сферах вращается”, и “все менеджеры козлы, нифига не понимают”. — квалификационный экзамен или техсобеседование на 30 минут исправят ситуацию. хотя можно и в морду получить за такое.
Кроме того, есть такая штука, как трудовой договор, в котором положено указывать, кто, что и кому должен, может и так далее. Который, увы, частенько не составляется, и все пускается на самотек. (или — должностная инструкция, которую сотрудник видит только случайно). — и дело непосредственного руководителя сотрудника эту информацию до его сведенья донести.
Потому что очень часто нет команды. — монолитные команды…. и потом, все зависит от конретной ситуации. команда — это группа людей, работающих над проектом. в идеале, “их восемь нас двое — расклад перед боем не наш, но мы будем играть…я этот небесный квадрат не покину. мне цифры сейчас не важны, сегодня мой друг защищает мне спину, а значит и шансы равны.” (с) В. С. Высоцкий, но это настолько редко встречается…
Да. А что будет, когда таки попытаются? — написать заявление об уходе дело 10 минут. у меня всегда лежит как минимум одно предложение о работе. сейчас 4. ах да, какое там заявление — я ж ЧП. встану и уйду.
по не соотвествию занимаемой должности
Все бы хорошо, только их никто не спрашивает. Они себе программисты, а их бац — и в управленцы-менеджеры.
и дело непосредственного руководителя сотрудника эту информацию до его сведенья донести.
Возвращаясь к моему предыдущему комменту (одному из) — по поводу документа о правах и обязанностях. Который исходно отсутствовал, после — был написан (самими же сотрудниками, для того чтобы таки определиться — кто есть кто, какие у кого права, обязанности и процедуры), и потом на этот документ благополучно забили.
То есть, фактически — у нас нет должностной инструкции.
написать заявление об уходе дело 10 минут
Вот именно. И это часто единственное решение.
>И это часто единственное решение.
Но мы не ищем простых путей!
Нет, все нормально. Вот вам и ротация.
так вобщем-то в чем проблема? я таких написал уже 4… нет 5. и ничего. живой.
да, вот действительно существуют несколько типов программеров – одни только тупо сделают что скажешь, другие будут ерепениться и в итоге сделают все по своему, сославшись на сто причин почему именно так, но заказчику это и не нужно будет, а другие сделают все нормально если им нормально все объяснить … и вот скажите где найти этих “нормальных”, у каждого свои завихрения ..чем опытнее и чем больше знает, тем больше завихрений… они просто начинают осознавать, что “власть” в их руках, ведь конечная реализация любого интернет проекта требует работы именно их рук …
не знаю бывает ли команда. скорее думаю если правильно управлять проектом, распределять обязанности, контролировать исполнение и т.д. – будет результат, не зависимо от того какие взаимоотношения и есть ли общие цели…
а вот тут, Дмитрий, я бы попросил Вас, как человека безусловно воспитанного и вежливого, вежливо и воспитанно извинтся. просто потому, что у меня 8 лет опыта разработки. наверняка у меня очень много “завихрений”, но Вы меня не знаете, поэтому я бы хотел, чтобы Вы перестали обобщать. я не имею привычки “ерепенится” и “делать что-то по-своему”, то что Вы работали с людьми, которые не понимаю смысла и сути работы в ИТ бизнесе, совершенно не означает, что таких людей нет.
и о власти. формально, власть принадлежит руководству компании. это по закону. но фактически, в реальности, все зависит от программистов. и если программисты уйдут, то проект провалится.
безусловно вы правильно заметили, что я человек воспитанный, поэтому приношу извинения если задел вас.
не думаю что любые комментарии здесь можно рассматривать как некие обобщения или объективные суждения, они deafault – субъективны. но думаю вы согласитесь – чем человек гениальней – тем более сумашедший, чем профессиональнее – тем более можеть быть самоуверен, иногда заносчив, наглее и т.д. (опять таки же – это не обобщение) …
принято.
про хамов с опытом — нет, не соглашусь. по двум причинам:
1) развитие личности, как правило, происходит гармонично. иными словами, чем больше у человека опыта и знаний, тем более адекватен его взгляд на мир. бывает и по-другому, люди ведь разные, но чаще всего именно так. просто пример, попадая в общественный траспорт я переодически нахожусь в недоумении. потому что бОльшую часть дня я окружен умными, амбициозными и воспитанными людьми.
2) воспитание — это одна из черт человка, которая не имеет прямой зависимости от опыта или возраста. воспитание, как правило, закладывается с дества. и чем более человек опытен, тем более он понимает важность и необходимость полученного воспитания. или же воспитывает себя сам. исключения редки.
а что до сумасшедших гение — это заблуждение общественности. просто гений знает и понимает то, что обычный человек понять не в состоянии. Уил Хантинг — это скорее исключение из правил, хотя если поместить гения в агрессивную среду (детдом, улица, армия) до того, как его личность оформится, возможен и такой вариант.
Ой, Антон, вы меня просто порадовали, честно!!!
Неужели вокруг вас на самом деле всегда встречались такие люди, что вы искренне написали этот комментарий и на самом деле в это верите?
Ну вот именно в данный момент я не про крайности (гении или полные отморозки), я вообще про среду, про наше общество. В частности срез этого общества в IT.
Это ведь всё те же люди – и в метро, и в офисе, и в ночном клубе, и на развлекательном чате… Есть золотая середина между мнением Дмитрия и вашим. Имхо.
Татьяна, я наверное удивлю Вас еще больше, если скажу что они мне продолжают встречатся? разумеется все что я пишу — я пишу искренне, к чему лукавить?
а люди они разные. и срез общества в ИТ немного другой, чем скажем в трамвае или метро. все-таки концентрация знаний на квадратный сантиметр нашего офиса намного больше, чем скажем на Барабашово. и это действительно теже люди, что и метро — теже, которые говорят “спасибо” выходя из маршрутки или такси, говорят “извините” наступая кому-то на ногу в переполненном вагоне, говорят “разрешите пройти” людям стоящим перед, придерживают двери… все те же люди. конечно это не только они, но они — люди окружающие меня — ведут себя именно так.
Ну, заносчивее и наглее может быть человек и без опыта. Эти параметры не зависят друг от друга…
Конечная реализация любого проекта зависит от работы всей цепочки — и менеджеров по работе с клиентами, и системных архитекторов, и дизайнеров, и маркетологов, и юзабилистов, и так далее, и так далее.
Это раз.
Два — если приходится контролировать выполнение, то что-то не так. Я вот, например, контролирую выполнение домашних заданий моим сыном. И то уже не сильно-то и контролирую. А ему всего 11 лет. Неужели к 25-30 годам сложно научиться контролировать себя самому? И эти люди считают себя специалистами?
Вообще, если уж на то пошло, то программист должен иметь хотя бы некоторое понимание того, что такое экономика, социология и прочие “никому не нужные предметы, которыми пичкают в институте”.
Одним C++ многого не сделаешь.
И, напоследок, цитата с Башорга —
“Хороший программист — это тот, который тупым кодом пишет гениальные программы. А не наоборот”.
дело не в том, сложно ли научится себя контролировать, хотя и в этом тоже. а в том, что за проект овечает конкретный человек. у которого таки больше опыта, который таки больше знает о рисках, о приоритетах и способен диагностировать проблемы на ранней стадии. это основы проектного менеджмента. и это совершенно не зависит от того, кто и как себя контролирует.
а по поводу программист должен — никто никому ничего не должен. программист совершенно не должен быть разносторонне развитым человеком, с подчиненными или членами команды совершенно не обязательно пить пиво по пятницам или дружить семьями. программист может выполнять свои служебные обязанности, если хочет получить деньги. только и всего.
каждый человек рожден свободным. это священное право даровано человеку Богом и Конституцией
Соедененных ШтатовУкраины.Если программист, кроме всего, будет знать экономику — у него не будет возникать нездоровых побуждений “сделать еще вот эту фишку”. Или вопросов “А для чего мы это делаем, это же никому не нужно!”
Это только вопрос эффективности.
Хотя да, от программиста достаточно выполнять то, что записано в служебных обязанностях. Обычно бОльшего никто не требует. Но если его приходится контролировать в этом выполнении — то проще найти другого программиста, которого контролировать не нужно будет…
Да, “контроль програмиста”, описанный выше, ничего общего не имеет с ревизиями кода и тестированием… Это разные вещи. Даже фраза — “Делает ли он” и “как он делает” — хорошо показывает разницу.
прости, мы вообще о каких программистах говорим? судя по твоим комментам — эти люди закончили среднюю школу. и то 9 классов. тчательнее нужно кадры подбирать… ну или больше времени уделять их подготовке. понимание основ бизнеса — это common sence, а не знание основ экономики. знание основ экономики — это способность посчитать себистоимость продукта, аммортизацию, что-то еще. я такую раскладку в дипломе делал. забыл уже. на позиции СТО может пригодиться, на позиции СЕО пригодится точно, а в ПМстве… к чему? тем более в инженерии.
и контролировать в любом случае придется всех и вся.
ревизии кода и тестирование есть неотъемлимые составляющие производственного процесса. это даже не управление проектом — это управление производством, компанией. правила установленные один раз. жизненный цикл проекта от business requirements до delivery. а я говорю о risk management, time management, resources management, configuration management. осуществлении передачи знаний, передачи опыта, ресурсов, эффективном использовании времени… вот это я понимаю под контролем. и программистов, которые будут делать это сами-по-себе тчетно. и не правильно.
Ну, подбор кадров — это не ко мне. Просто — так уж получилось. Хотя да, эти люди (в большинстве своем) закончили институты, получили дипломы… Но это как раз не играет роли.
это способность посчитать себистоимость продукта, аммортизацию, что-то еще
Хотя да, это не к PM. Его задача — сделать проект, а не решить, нужно его делать или нет.
Ну, это — часто — позволяет также посчитать, есть ли смысл делать проект вообще
ревизии кода и тестирование есть неотъемлимые составляющие производственного процесса. это даже не управление проектом — это управление производством, компанией.
Да, это составляющая процесса (равно как и написание ТЗ, создание прототипов, и прочие прелести разработки). Но тут речь не об этом.
risk management, time management, resources management, configuration management. осуществлении передачи знаний, передачи опыта, ресурсов, эффективном использовании времени…
Антон, я пока что (за свою, правда, недолгую карьеру) таких менеджеров, которые бы делали это все, не видел. Ни менеджеров, ни программистов.
Риск менеджмент — это “давайте накинем процентов 20 времени на всякий случай”.
Resource Management часто заключается в следующем: “Ты сейчас свободен? Тут проект намечается, готовься”.
Про time management, configuration management, передачу знаний и так далее — вообще речь не идет. Все “как-нибудь сами”…
Процесса, как такового, нет… Он нигде не описан, каждый делает во что горазд…
Может, действительно, поступить по методу Антона Наумова?
задача configuration management часто решается силами команды. это правда и довольно часто это оправдано. другое дело, что задача ПМа координировать действия команды таким образом, чтобы эта деятельность была минимальной и эффективной. я предпочитаю настравать конфигурацию сам и спускать в команду guidelines. но вполне возможно, что один из членов команды будет более компетентен в кофигурировании того или иного артефакта — тогда это его задача. на которую тоже выделяется время.
risk management — это та тема, которую я сечас пытаюсь освоить. которая мне определенно интересна.
resource management — это вообще одтельная песня и отдельная отвественность. и хоть конечным результатом является именно та фраза, которую ты описал, но ей предшествует очень и очень много анализа и информации, которая доступна.
time management — это и есть тот контроль, о котором я говорил. у ПМа не должно быть ситуаций, когда один программист надрывается на кучей тасков, а второй — сидит на баше. прицип “сделал свою работу, найди себе другую” должен быть.
передача знаний и опыта — я всем настоятельно рекомендую заводить Wiki и выделать 5-10% времени разработки на написание статей о тех tips&tricks, solutions, workarounds and problems которые были разработаны за некий период. обычно неделю. это безусловно полезно. ежеденельные митинги относятся сюда, к тим билдингу и time management. 5-10 минут в неделю для каждого из членов команды, чтобы он рассказал что он делал, что собирается делать, какие были проблемы и где он описал их решения. лично у меня роль в том числе и моей собственной базы знаний играет два блога.
как ты понимаешь, я это делаю. а что не делаю, то пытаюсь делать. на текущий момент моя ПМская активность оставновилась, но надеюсь что это не на долго.
и последнее, если работа вместо радости и удовлетворения приносит раздражение и уныние, то нужно менять место работы, а может быть и вообще род занятий. таков мой метод.
задача configuration management часто решается силами команды. это правда и довольно часто это оправдано.
Для этого, опять таки, нужна команда. То есть, в первую очередь — коммуникация.
К сожалению, я не знаю, почему так происходит, но — бОльшая часть знакомых мне программистов даже не пытаются документировать свои наработки в каких-то областях… Ну, и возникают случаи, когда за двумя соседними столами сидят два программиста, которые делают одно и то же, натыкаются на одни и те же грабли… Только с запаздыванием примерно в неделю… И никто никому ничего не сообщает.
Возможно, одна из причин — “сдельная оплата” — то есть, первый программист, который продрался через дебри библиотек и потратил 20 часов вместо 10 — получит зарплату за 10 (и еще 10 — за свой счет), а второй, в случае если первый опишет все эти бока — аналогичную задачу сделает за 5 часов (и получит за 10, то есть 5 часов в плюс). Естественно, первому программисту невыгодно описывать свои решения — в этом случае он хотя бы сможет аргументировано (”Вот, не только я потратил на это 20 часов, все тратят по 20 часов”) “выбить” из менеджмента те самые 10 часов. И для себя, и для других программистов с теми же “затыками”.
Что, соответственно, невыгодно ни компании, ни заказчику… Но — такова схема работы.
risk management — это та тема, которую я сечас пытаюсь освоить. которая мне определенно интересна.
Ну, глядя со своей колокольни — эта штука действительно сложная. Особенно в случае задач, которые ранее не встречались.
resource management — это вообще одтельная песня
Да. Этому нужно учиться (и никакие ms project-ы тут не помогут) — особенно сложно понять, что этапы разработки нелинейны, человеко-часы это нечто абстрактное и не соответствует действительности (за сколько времени 10000 кошек съедят одну мышку?), помнить что есть эффект переключения задач, знать кто что лучше умеет (нет смысла сажать PHP программиста на документирование ASP модуля в то время, как ASP разработчик изучает AJAX). И прочие мелочи…
прицип “сделал свою работу, найди себе другую” должен быть.
Да, это хорошо бы. В тот период, когда у нас была такая возможность — так и делали. Подходишь к PM-у, говорить “я тут освободился”, берешь проект, смотришь, выбираешь таски которые можешь сделать, делаешь… Все довольны и счастливы.
В случае же, когда один человек занят на трех проектах одновременно — это плохо. Но это случается все чаще и чаще…
Насчет “базы знаний” — да, я специально для этого завел публичный блог, в котором пишу статьи о том, что мне встретилось (и пригодилось). Ну, и локальное хранилище “необхрдимых программ” — то есть, все что нужно для быстрого развертывания рабочего места. Уже второй год весь отдел кушает, нахваливает и не оплачивает
))
Но, насчет “если работа приносит уныние” — скорее всего, так и прийдется поступать. Потому что — поддержка проектов превращается в поддержку заказчиков… (и обычно — “у нас там скрипт нужно подправить”, а мы с вами уже работали)… А я ведь могу гораздо большее… Но — забит всякой мелочью, которую бы новичкам давать, как раз для разгона и тренировки… А так — ни себе, ни людям…
скоро окошко уменьшится до одного символа
две ремарки:
1) если их менеджера нужно “выбивать” оплату за время, то это совершенно негодный менеджер. information should be free and should be shared. и никак иначе. и платой за эту информацию является то, что это твои знания и твоя записная книжка. тебе не придется делать одну работу несколько раз.
2) если надумаешь менять работу, как-раз походящий период. рынок перегрет. найдешь без проблем.
1) Ну так все просто — чем меньше получит программист, тем он “выгоднее”.
Тут вообще палка о двух концах. Есть люди, которые на постоянной ставке работать не могут — начинают башорг читать круглосуточно… А есть те, которых необходимость протоколировать в таймшитах каждый чих просто размазывает…
2) Да, очередная ротация
Судя по предложениям работы — старые ушли, нужны новые.
Командная работа и авторитетный тимлидер:
[...] позапрошлой записи о цыплятах речь шла о том, что не только в гиблых конторах, но и [...]
Приманки – чем удержать сотрудника.
[...] темы “о цыплятах” и “командной работе” — разговор, затеянный в [...]