×

За что увольняют программистов

Хороший программист — это не обязательно хороший сотрудник. И как бы ни была сейчас ценна профессия айтишника, даже талантливых специалистов иногда увольняют с работы. Давайте разберемся, почему.

Код ради кода

«Наняли человека — хорошо прошел собеседование. Миддл. Сам меня нашел через DOU», — рассказывает Владимир Железняк, СТО небольшой продуктовой компании FundSeeder.

Через неделю ознакомления/работы новому сотруднику дали задачу — дописать пару строчек («отправить письмо по действию пользователя, см. пример, как мы это делаем вот тут»). В результате оказалось, что он переписал много старого кода, подтянул пачку новых библиотек.

По мнению руководства, для миддла на второй неделе работы в большом проекте — такое поведение несколько неожиданно. Когда выяснили ситуацию, оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик. Тогда ему объяснили, что о рефакторинге можно будет поговорить спустя несколько месяцев, когда он в достаточной мере поймет проект, а пока от него требуется просто выполнение задач по разработке.

В итоге эту задачу с отправкой письма возвращали на доработку два раза — и каждый раз там в коде было нечто очень неожиданное — новые директории, новый API и т.д. Это всё хорошо — но тогда, когда оно действительно нужно. Часто решить проблему можно намного проще и менее затратным способом — стоит только вникнуть и разобраться.

Чуть позже возник еще один случай — на двухнедельном Iteration Review подняли проблему, что есть задержка в несколько дней между запросом от пользователя и ответом саппорта. Новый сотрудник начал предлагать решения, какие тулзы и сервисы можно прикрутить. Но это всё уже и так было. Выяснили, что проблема появилась из-за неверного назначения ответственного сотрудника в сервисах. А разработчик бросился предлагать решения, не понимая проблемы.

Сотрудника уволили на третьей неделе работы — за непонимание связи между написанием кода и бизнес-потребностями проекта.

А нам всё равно

О следующем случае рассказал Алексей Колупаев, СТО стартапа MeinFernbus. Когда искали программиста на одну из вакансий, им подвернулся кандидат, который не знал нужного фреймворка. Тогда ему предложили написать что-то на этом фреймворке для себя, придумать и реализовать простенький проект. В 90% случаев соискатели после такого исчезают, но этот разработчик выполнил задание, показал нормальный результат, и его приняли.

Со временем, когда спала повышенная работоспособность, свойственная только что нанятым сотрудникам, оказалось, что новый сотрудник регулярно косячит, но не видит в этом какого-то экстраординарного явления, takes it easy. В принципе, человеку свойственно ошибаться, еще и новому. Но неприятные моменты накапливались. Выводы не делались.

Компания в то время была стартапом на очень ранней фазе, но уже добились определенных успехов, темп был очень высоким. В один из поздних вечерних деплоев на продакшн попал очень неприятный баг, который случался в каждом букинге. Откат деплоя не помог. Букинги с ошибкой поступали. Через два часа выяснилось, что баг проистекает из неправильной конфигурации на сервере. Нового сотрудника в офисе уже не было, а по телефону он сказал, что уже вечер, он отдыхает, утром придет в офис, тогда и разберется.

После этого компания прервала его испытательный срок.

Сам себе на уме

Этот пункт посвящен непроработанным soft skills и навыкам личной эффективности.

Алексей Коваль, СТО проекта UA2WEB, сталкивался с ситуаций, когда проект перерос одного человека, а этот человек оказывается неспособным перестроиться с работы в одиночку на труд в команде. Выглядит это так: проект начинает один человек, проект растёт, неизбежным становится участие большего количества исполнителей, менеджеров, а человек не может интегрироваться, не может или не желает общаться с другими людьми, принимать коллективные решения. Возможно, он пишет неплохой код, его работа как раз и привела к успеху проекта, но на этапе присоединения других участников его приходится увольнять

Но, по словам Алексея, первая по количеству увольнений статья — это некачественная работа, когда человек, обладая знаниями и умениями, не выполняет задание из-за проблем с личной дисциплиной и организованностью.

Еще один кейс, о котором стоит упомянуть — когда специалист не желает выстраивать отношения с менеджментом компании. Такой случай был в практике Насти Шафрановой, hr-менеджера Timecode. Разработчик, хороший технический специалист, полностью игнорировал рабочие миттинги, не предупреждал, что у него не получается присутствовать. Пришлось с ним попрощаться после испытательного срока.

Похожая ситуация — некорректное поведение с заказчиком. По словам Сергея Немчинского, тимлида в IntroPro, если разговор об аутсорсе, то за подобные промахи людей увольняют в 24 часа. Слишком уж аутсорс зависит от заказчика. Жестоко, но вариантов нет — найти нового разработчика существенно проще, чем заказчика


P.S. Есть еще одна категория fire-листа — невыполнение рабочих обязанностей. Бывает, что человек старается, а результатов мало. Но тут, пожалуй, и так всё понятно.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

В один из поздних вечерних деплоев
ОДИН ИЗ
поздних вечерних деплоев

This.

Компания на постоянной основе деплоится по вечерам, когда у сотрудников уже кончился рабочий день.

Сотрудник сказал «разбирайтесь с проблемой сами»? Нет, он сказал, что разберётся с ней в рабочее время.

Стартаперы не могут в понимание, что потребность в овертайме, да ещё и на испытательном сроке, это проблема, в первую очередь, процессов компании.

По поводу ситации «Сам себе на уме». Наблюдал ситуацию:
1. Чувак сам за год поднял с нуля проект — один работал сутками. Проект действительно был хорошо сделан.
2. Наняли манагеров, которые его контролировали — были случаи, 3 манагера на одного чела — пока не наняли других исполнителей.
3. Чувака не особо слушали — он перестал коммуницировать с менежментом.
4. Через пару месяцев его уволили — сам себе на уме.
5. Вновь прибывшие программисты начали переписывать проект — причины не знаю — итог: было завалено несколько релизов.
6. После нескольких заваленных релизов было принято решение, что самый первый программист неправильно писал: итог — все глобально отрефакторить.
7. За полгода рефакторинга ни одного релиза. Дальше не знаю.

Нового сотрудника в офисе уже не было, а по телефону он сказал, что уже вечер, он отдыхает, утром придет в офис, тогда и разберется.
Всё правильно сделал. Удачи тебе, друг, на новом месте. Ты ничего не потерял.

в первой истории я на стороне программиста, если ему явно не было сказано об ограничениях и качестве кода, который от него ожидается (желательно на собеседовании, чтобы изначально не соглашаться) — то нечего пенять...

во второй — нейтрально, бывает, что человек просто рассчитывал на грамотный процесс, что его баги выловит умелый тестер. Иначе будет ситуация как в первой истории, чувак возится с чем-то таким, что от него не ожидают, фиксает баги, которые никто и никогда не воспроизведет, время идет, сроки срываются.

Третий — это баг менеджмента, они себе в головах попридумывали (или что чаще, где-то прочитали в умных интернетах) что все плохо, и все надо менять, и вторглись в зону комфорта человека, который на себе тянул весь проект. В конце-концов — это их решение и их ответственность, но не правильно будет ставить в вину программисту, что он не вжился в их фишечку. Менеджеры зарабатывают на свой сникерс тем, что постоянно что-то «улучшают» и контролируют, программисты тем, что кодят. Ведь никто не будет рассказывать какому-то художнику, что он должен свои картины рисовать в костюме с галстуком, при этом улыбаясь в 32 зуба — и мало кто понимает, что коддинг это тоже искусство.

В статье прекрасно все: иллюстрация из низкопробной сортирной пропаганды обиженных французов, поверхностное и однобокое описание кейсов, выставляющих авторов рассказов в категорически невыгодном свете. Комментарии, опять же :)

Если брать истории «как есть», не начиная по-декартовски сомневаться или искать мнения другой стороны — все три истории об ошибках менеджмента и кривых процессах.

История 1:
1. Что продали на собеседовании — то разработчик и ожидает.
2. Когда ставят задачи новичку в проекта — с ним решение не согласовывают до начала написания кода?
3. Если уж не согласовали решение до начала работ — код-ревью не делают для новичка?
4. Дописать пару строчек, используя готовые компоненты — оценку никто не потребовал? Раз новичок — пусть пару строк неделю пишет?
5. Ценность задачи в пару строк для внедрения в проект? Вот и полез готовые компоненты рефакторить, чего хотели-то?
6. Посмотрели со стороны коллеки на инициативу новичка и подумали: «а ну его нафиг — инициативу проявлять, уволить». Старый принцип наказывать за бездействие, а не за действие (не совсем глупое, а по незнанию) — перестал работать?
7. А новичку рассказать о жизненном цикле фичи/бага и тулзах, которые его сопровождают — это разве не третья задача куратора новичка?

Итого — человек уволен за полностью прощелканный ввод его в проект и процессы. Вполне вероятно, что были причины объективные — занятость срочным проектом, например. Но неча тогда на зеркало пенять.

История 2:
1. Вечерний разрушающий безоткатный деплой должен быть прикрыт тестировщиками и авторами кода на подогреве, чтобы быстро исправить — иного боги девелопмента не прощают. Договориться с командой о смещении рабочего дня/овертайме/... — нет? О целях и значимости билда поговорить, связать его с бизнес-целями компании и благосостоянии команды — нет? Чтобы сами рвались деплой поддержать, как это обычно бывает. Или просто обмен некоторого времени на некоторые бабки?
2. За баг, пролезший на деплой вопрошают и наказывают (если наказания есть как класс) не только автора, но и тестировщиков каждого из кругов тестирования, ответственного за ревью процессов, нацеленных на предотвращение деградации, ответственного за сами процессы. Или работа ведется в стиле простого одношагового мышления?
3. Инженерная работа по умолчанию сопряжена с ошибками. Особенно — итеративная. Нет? Из пассажа о безразличии отнюдь не следует, что косячил всегда на сходных задачах + непонятно, куда смотрел менеджмент + непонятно, как работали над ошибками.
4. Откат деплоя не помог — а он тестировался? План B, C, ... на выкладках есть вообще или «Наполеоны в угаре»? Конечно, после такого чисто психологически хочется кого-то уволить, сами же совсем не виноваты :)
5. На зеркале/клоне/неактивном ядре/.. продакшена потестировать билд и найти ошибку до её массового релиза — нет?

Итого — в компании кривые процессы тестирования и деплоя + разрыв в целях команды/компании и разработчиков. Баг причинил боль, захотелось причинить боль кому-то ещё и автор бага — очевидный вариант. Несмотря на то, что отвечают как минимум трое..пятеро за пробой продакшена, в зависимости от сложности процессов. Ожидаем повторения истории.

История 3:
1. Давайте накажем интроверта за то, что он интроверт?
2. Создать рабочую группу из одного человека в проекте труднее, чем уволить разработчика, поднявшего проект?
3. А коллеги сами-то точно умеют работать в команде? А то выглядит, как будто «девочки подружили против кого-то».
4. Расширение команды привело к новым процессам. По этим процессам была внутренняя продажа, был ли вовлечен человек в обсуждение и формирование процесса как такового? Или все в классическом стиле: «я прочитал умную книгу и с понедельника вы живете по-новому»?
5. Обратная связь о митинге, его целях и проблемах, которые будут обсуждаться — получены? Лежат они в поле ответственности разработчика?
6. Рассматривал ли кто-то поведение разработчика как молчаливый протест?
7. В чем именно некорректность поведения с заказчиком? А старый закон оутсорса, что без присмотра разработчика к заказчику пускать нельзя — не работает?

Итого — гибкая стратегия и тактика развития проектов и сопутствующих процессов отсутствует как класс. Менеджеры выглядят склонными к мелочному авторитаризму и бытовому насилию.

553 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

За картинку конечно спасибо, посмеялся — но судя по тексту она как раз и отражает отношение автора к программистам так что смешного мало. Чувак себя видит солдатом с длинным ружьем а программиста — стоящего перед ним раком со спущенными штанами. Да вы, батенька, шалунишка.

Хоть и тема древняя, но.

В итоге эту задачу с отправкой письма возвращали на доработку два раза — и каждый раз там в коде было нечто очень неожиданное — новые директории, новый API и т.д. Это всё хорошо — но тогда, когда оно действительно нужно. Часто решить проблему можно намного проще и менее затратным способом — стоит только вникнуть и разобраться.

Часто бывает, приходишь на проект, а там — чуть ли не ассемблере всё написано.
И решение текущей задачи просто ведёт к усложнению кода и увеличению затрат на поддержку, что приведёт проект в никуда, т.к. каждую новую фичу вы будете внедрять неделями, спотыкаясь о старые грабли.
Рефакторинг — это то, с чего работу над таким проектом нужно начинать.
И тот факт, что вы с самого начала не сказали разработчику на собеседовании, что проект у вас написан с использованием старых технологий и рефакторинг не планируется в ближайшее время. В этом случае, человек бы скорее всего, вынужден был отказаться от сотрудничества. Или вы сами бы сказали, что ваши краткосрочные и среднесрочные цели с кандидатом не совместимы. Я сам так однажды не попал в крупную аутсорс контору, т.к. на собеседовании с пиэмом мы выяснили, что у нас разные среднесрочные приоритеты. У меня — сделать из проекта легко масштабируемую и поддерживаемую конфетку, переписав всё на современные технологии и архитектуры. У них — срочные фичи заделиверить. В итоге, на этот проект взяли не меня, а моего знакомого, который был менее переборчив в технологиях. О чём в итоге, ни я, ни компания, ни этот знакомый ни разу не пожалели все в итоге получили что хотели.

Когда выяснили ситуацию, оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик.

Знайома ситуація. Вангую, ви йому самі про це впарювали на співбесідах:
кококо, follow best practices, keep code clean and readable...

Треба зразу казати правду: маєм проект зліпленний з говна і палок, твоя задача: доліплювати нові палки старим гівном.

Але якшо так казати, то попруть когось іншого: менеджера, HRa, etc.

Это истории не проблем девелоперов, а проблемы менеджеров. Каждый менеджер себя ставит на ступеньку выше, что и приводит к подобному.
Единственное с чем согласен, это не позволительное отношение с заказчиком или наплевательское отношение к команде.

Когда выяснили ситуацию, оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик. Тогда ему объяснили

переводим с менеджерского на русский — нормально НОВОМУ сотруднику никто ничего не обьяснил, задачу нормально не поставил а потом его сделали еще и крайним.
Как там оно у классика, «алчные программисты которые не интересуются миссией компании», не иначе...

"

В один из поздних вечерних деплоев на продакшн попал очень неприятный баг, который случался в каждом букинге. Откат деплоя не помог.
"

А как вообще процесс разработки поставлен что даже откатить не получается ,
тут нужно увольнять тех. лида а не разработчика , за то что так все организовано , - нет тестов , PR review, и тд. В статье много чего с ног на голову ,

На моей памяти из разных проектов увольняли программистов:

а) по причине забивания на работу. ну раз на неделю профакал сроки, ну два, ну три — оп, вообще затянул дурную бесконечность. может, недомотивировали. может, у человека началась внезапно семейная жизнь и приоритеты поменялись.

А, например, из-за войны я сам не смог держать темп и ушёл с работы. Внезапно стало необходимым разрулить столько всего, что трындец. Потом попустило, но отпуска на год редко где дают.

б) по причине «чот ты нам не нравишься». и тут даже не в интроверсии вопрос: вот просто рожей и манерами не вышел, руководство не понимает этих странных приезжаний в офис на самокате. здесь я придерживал вожжи, пока это было разумным, но в итоге оставлял на откуп руководству: лучше пусть человек найдёт нормальное место, где на него не будут так нависать.

За мегафейлы не увольняли никого. Потому что фатальных фейлов не было даже с ракорукими обезьянками, которым просто не давали влезть клешнями во что-то слишком чувствительное без хорошей изоляции от продакшена.

За попытки сделать из любой задачи проект с привлечением всех технологий и фреймворков, с которыми девелоперу захотелось поиграться, не увольняли. Хотя такие люди попадались. Хватало и простых объяснений, что делать, почему и зачем, и в каких ситуациях с какими согласованиями стоит внедрять что-то ещё.
Но если погромисту всё-таки было неинтересно работать без постоянных изысков, он уходил сам. Имеет право.

Нелюдимых спецов, кстати, окучивали прекрасно. Если нормально наладить проработку задач (что из-за моей лени делается по умолчанию: неохота лишний раз дёргаться), то никакая интроверсия не мешает. Да пусть хоть аутист с аллергией на людей: если умеет выдавать бриллианты — пускай сидит в своём хрустальном танке, общаясь морзянкой через шлемофон.
Все ведь разные, и набычить на трезвенника за то, что подрывает дух коллектива, не участвуя в совместных пьянках — много ума не надо, а убыток будет.

p.s. хихикс; в бедже на DOU до сих пор NetStyle. прикольные были времена...

Самокат для Киева — самое то.

Как по мне то во случаи можно подвести под miscommunication, проблема всех. p.s. а за статью спасибо, эдакий In site чего ожидает работодалель от потенциальных сотрудников, было бы еще лучше указывать это в описании вакансии вместо миллиона технологий которые реально используются на 10% возможностей.

Во втором случае самый сок «синьоры» местные упустили....

> Откат деплоя не помог. Букинги с ошибкой поступали. Через два часа выяснилось, что баг проистекает из неправильной конфигурации на сервере.

То есть конфиги накатили, но не откатили с откатом деплоя -> конфиг менеджмент не известен либо программеру которого за это в совокупности с предыдущими заслугами поперли, либо тем кто делал деплой -> ну и тогда наш герой не много потерял покинув этот славный стартап с поломанными процессами.

Давно я такого не писал, но статья КГ\АМ

За плохую работу ПМов и тимлидов :)

В статье прекрасно все: иллюстрация из низкопробной сортирной пропаганды обиженных французов, поверхностное и однобокое описание кейсов, выставляющих авторов рассказов в категорически невыгодном свете. Комментарии, опять же :)

Если брать истории «как есть», не начиная по-декартовски сомневаться или искать мнения другой стороны — все три истории об ошибках менеджмента и кривых процессах.

История 1:
1. Что продали на собеседовании — то разработчик и ожидает.
2. Когда ставят задачи новичку в проекта — с ним решение не согласовывают до начала написания кода?
3. Если уж не согласовали решение до начала работ — код-ревью не делают для новичка?
4. Дописать пару строчек, используя готовые компоненты — оценку никто не потребовал? Раз новичок — пусть пару строк неделю пишет?
5. Ценность задачи в пару строк для внедрения в проект? Вот и полез готовые компоненты рефакторить, чего хотели-то?
6. Посмотрели со стороны коллеки на инициативу новичка и подумали: «а ну его нафиг — инициативу проявлять, уволить». Старый принцип наказывать за бездействие, а не за действие (не совсем глупое, а по незнанию) — перестал работать?
7. А новичку рассказать о жизненном цикле фичи/бага и тулзах, которые его сопровождают — это разве не третья задача куратора новичка?

Итого — человек уволен за полностью прощелканный ввод его в проект и процессы. Вполне вероятно, что были причины объективные — занятость срочным проектом, например. Но неча тогда на зеркало пенять.

История 2:
1. Вечерний разрушающий безоткатный деплой должен быть прикрыт тестировщиками и авторами кода на подогреве, чтобы быстро исправить — иного боги девелопмента не прощают. Договориться с командой о смещении рабочего дня/овертайме/... — нет? О целях и значимости билда поговорить, связать его с бизнес-целями компании и благосостоянии команды — нет? Чтобы сами рвались деплой поддержать, как это обычно бывает. Или просто обмен некоторого времени на некоторые бабки?
2. За баг, пролезший на деплой вопрошают и наказывают (если наказания есть как класс) не только автора, но и тестировщиков каждого из кругов тестирования, ответственного за ревью процессов, нацеленных на предотвращение деградации, ответственного за сами процессы. Или работа ведется в стиле простого одношагового мышления?
3. Инженерная работа по умолчанию сопряжена с ошибками. Особенно — итеративная. Нет? Из пассажа о безразличии отнюдь не следует, что косячил всегда на сходных задачах + непонятно, куда смотрел менеджмент + непонятно, как работали над ошибками.
4. Откат деплоя не помог — а он тестировался? План B, C, ... на выкладках есть вообще или «Наполеоны в угаре»? Конечно, после такого чисто психологически хочется кого-то уволить, сами же совсем не виноваты :)
5. На зеркале/клоне/неактивном ядре/.. продакшена потестировать билд и найти ошибку до её массового релиза — нет?

Итого — в компании кривые процессы тестирования и деплоя + разрыв в целях команды/компании и разработчиков. Баг причинил боль, захотелось причинить боль кому-то ещё и автор бага — очевидный вариант. Несмотря на то, что отвечают как минимум трое..пятеро за пробой продакшена, в зависимости от сложности процессов. Ожидаем повторения истории.

История 3:
1. Давайте накажем интроверта за то, что он интроверт?
2. Создать рабочую группу из одного человека в проекте труднее, чем уволить разработчика, поднявшего проект?
3. А коллеги сами-то точно умеют работать в команде? А то выглядит, как будто «девочки подружили против кого-то».
4. Расширение команды привело к новым процессам. По этим процессам была внутренняя продажа, был ли вовлечен человек в обсуждение и формирование процесса как такового? Или все в классическом стиле: «я прочитал умную книгу и с понедельника вы живете по-новому»?
5. Обратная связь о митинге, его целях и проблемах, которые будут обсуждаться — получены? Лежат они в поле ответственности разработчика?
6. Рассматривал ли кто-то поведение разработчика как молчаливый протест?
7. В чем именно некорректность поведения с заказчиком? А старый закон оутсорса, что без присмотра разработчика к заказчику пускать нельзя — не работает?

Итого — гибкая стратегия и тактика развития проектов и сопутствующих процессов отсутствует как класс. Менеджеры выглядят склонными к мелочному авторитаризму и бытовому насилию.

Менеджеры выглядят склонными к мелочному авторитаризму и бытовому насилию.Круто:))

>> Сам себе на уме

Этот пункт посвящен непроработанным soft skills и навыкам личной эффективности.

Так надо ж было отравить его вначале к Владимиру Железняку из первого случая, для повышения софт скилов :D

История 1. Если действительно поставлена была задача

«отправить письмо по действию пользователя, см. пример, как мы это делаем вот тут»
то я на стороне компании. Если же «как мы это делаем вот тут» — были пустыми словами, то и не в чем обвинять программиста. Кодить же изначально «как надо» — это из серии «копать траншею от меня и до обеда».
История 2. Без комментариев. Деплой по вечерам, стажер на конфигурации важных серверов, телефонные вызовы в нерабочее время. Такие стартапы must die. Вместе с менеджментом.
История 3. Грустная. Вот так обычно программеров и «кидают». Очень часто даже «создают» описанную ситуацию. Я вижу выход один — каким-то образом юридически прописывать финансовую ответственность менеджмента (владельцев) перед (де-факто) идейным/системным архитектором приложения в виде большого размера «финансового парашюта» на случай возникновения таких вот непониманий с любой из сторон.
P.S. Менеджмент компаний часто забывает, что у них тоже есть ответственность перед нанятыми сотрудниками (финансовая, в выполнении КЗоТа и т.д.), которая не зависит от текущего финансового положения проекта. Нет денег — не нанимай сотрудников. Но не нужно свои управленческие и финансовые просчеты «выплескивать» в виде обвинения в отсутствии патриотизма у сотрудников. Сотрудник не обязан быть «патриотом». Он обязан четко выполнять прописанные в контракте задачи.
P.P.S. Я все больше склоняюсь к мнению, что программистам с достаточно большим опытом после определенного возраста работать в стартапах большого смысла не имеет.

1) Очень мутная история. Воспринимается как «парень хотел как лучше и сделал больше, а от него ожидали monkey job» И за это его ... выгнали.
2) Ваще жесть.

. В один из поздних вечерних деплоев на продакшн
Дальше можно не продолжать. В проекте очень «крутой» СТО и отдел контроля качества. Ах да, стартапам все можно?) На прошлом месте занятости, когда в выходной ночью случился какой-то критический баг на лайве, никто никому не звонил. Их фиксил СТО ;)
3) Говно-митинги, больше их! Наступит ли тот светлый день, когда главнейшим условием на позицию ПМ станет наличие технического бекграунда. Глядишь, и число митингов в компаниях «в среднем по палате» уменьшится, и хорошие специалисты будут четко понимать, «что я здесь забыл».

ну да, технический бэкграунд как раз направлен на «осознание потребностей команды, обсуждение приоритетов и проблем без произнесения ни одного звука и находясь в идеале в другой стране».

Ок, подробнее: для того чтобы корректно и правильно те самые потребности осознать и понять приоритеты, увидеть истинные проблемы, этот самый технический бекграунд и нужен ;)

Ыыыы я помню меня Ab Soft уволил (первый раз вообще). Пять пунктов перечислили, первым был «Ты дико напрягал нашего HR»
Напрягал я его дико то что вышел на 4 дня позже, чем они себе придумали, а вышел я на 4 дня позже потому что начал работать у них на 4 дня раньше чем официально был оформлен (летал в командировку по их же просьбе). При этом предупредил их что выйду на 4 дня позже т.к. мне нужно было закрыть дела в конторе откуда я уходил, о чём они забыли.

Все истории должны были закончиться пинком под зад манагеру. В идеальном мире.
В реальном мире наиболее распространённая ситуация выглядит так — компания как собака блох насобирает бесперспективных проектов, под них наберёт несбалансированные команды, потом проекты умирают от естественных причин и людей сокращают потому, что компания в них не вкладывалась и вообще компании на них наплевать. Аутсорс и ничего личного.

Добавила в первый пункт уточнение ситуации:

Чуть позже возник еще один случай — на двухнедельном Iteration Review подняли проблему, что есть задержка в несколько дней между запросом от пользователя и ответом саппорта. Новый сотрудник начал предлагать решения, какие тулзы и сервисы можно прикрутить. Но это всё уже и так было. Выяснили, что проблема появилась из-за неверного назначения ответственного сотрудника в сервисах. А разработчик бросился предлагать решения, не понимая проблемы/

Набор слов какой-то. Я так понимаю, что смысл абзаца тут:

разработчик бросился предлагать решения, не понимая проблемы
Учитывая, что «Сотрудника уволили на третьей неделе работы», времени въехать в проект ему не дали. Некогда точить топор — рубить надо.

Если уж компания решила оправдываться — могла бы продумать, что говорить.

FB с шестинедельным буткампом нервно курит в сторонке)

Компания не оправдывалась — мне сразу Владимир тогда рассказал и про это тоже, просто я не добавляла в статью, чтобы не перегружать деталями.

Це взагалі шикарно, пишуть, що людина мідл, навіть не сініор або тімлід, людині дали розбирати проект, який вона сама за два тижні не до кінця розібрала. Тобто банально навіть ніхто не сів і не поговорив з новим членом команди про проект, не розповіли які тулзи і які сервіси є на проекті і найголовніше, які нагальні проблеми існують( одне з перших, що мав би зробити тімлід чи хоча б один із працівників ). Природньо, що розробник побачив проблему і вирішив її пофіксати. Набагато б гірше було, аби він проблему вирішив не помічати чи мовчати про неї або взагалі б вставив якийсь костиль чи заглушку яка б замаскувала баг.
Після уточнення менеджер в моїх очах ще більш не правий.

Новый сотрудник начал предлагать решения, какие тулзы и сервисы можно прикрутить.
И что? В чем проблема? Человек не знал и предложил.

боюсь, Валентина не сможет ответить :(
а вообще, это известная проблема: инициативность.
предлагают, предлагают, внедряют, делают, добиваются.
сложно имитировать деятельность из-за таких :(

боюсь, Валентина не сможет ответить :(
думаю, это вопрос не ко мне, я же не делаю оценки, что было хорошо, что плохо, а просто пересказываю то, что мне ответили на вопрос: «Расскажите пару интересных историй, когда вам приходилось уволить разработчиков, почему?»

а призвать тех, кто рассказывал про кейсы можете?
если нет — вопросы так и останутся висеть в воздухе.

Какой-то бред. Никто никогда не понимает ситуацию полностью. Сотрудник проявил инициативу, а его уволили за это? Какие-то вести из Лузервиля. При таком подходе — никто больше не проявит инициативы, «Инициатива — наказуема!», больщой привет лучшим практикам рашистско-совкового менеджмента, и итог — тот же.

Думаю слід розрізняти випадки «проявив ініціативу» і «замість вирішення конкретної невеликої задачі поліз ’робити все правильно’ почавши переписувати пів проекту». :)

Что-то все эти «увольнения» от разработчиков не зависят.
Как можно давать человеку неделю на задачу, а потом выяснять, что он сделал ее не так — а статус ежедневный?
На счет «я дома, отдыхаю» — вполне законно, так как работет над проектом команда — то и отвечает команда, а не разработчик. Ревью — чтобы больше 1 человека знало о том, что в коде, который работает.

Сам увольнял только по причине систематического невыполнения задач. Сейчас понимаю, что надо было давать больше времени на разобраться, вникнуть — но условия диктовал не только я, но и заказчик.

Как будто бы люди абсолютно заменяемы, и прямо команда как целая за все отвечает

Нет абсолютной замены, но мы успешно можем продолжить разработку напарника. Разумеется, чем выше уровень разработчика, тем сложнее менее опытному продолжить после него.

Та самая ситуация, когда девелоперу самому нужно бежать из таких компаний.

off-peak, это когда девелопер спит ))
Из своей личной практики — скажу, что когда мы деплоили «кусочки кода» связанные с NYSE или NATO, то _вся_ команда была на расстоянии вытянутой руки.

Алексей, судя по комментариям — тут тусят программисты от кода которых ничего не зависит :)

Похоже тут тусят те кто не живет одной только работой.

значит у нас похожие взгляды на жизнь ))

Я вообще против деплоев. Как утренних, так и вечерних.

а меня умиляет позиция что какой-то хрен решил работать в нерабочее время и считает что ему все должны

а как же непрерывная интеграция и прочие модные штучки? работа через боль должна сопровождаться болью, работать 24/7, при договоре 40 часов в неделю никто адекватный не будет

нельзя было допускать форс мажорных ситуаций, нужно возвращать бекап и отменять апдейт, потом в рабочее время уже разбираться

Вот это мне очень понравилось, насчет нельзя допускать. Абсолютный же бред.
Уменьшать их количество, пытаться управлять ими — да. Но как не допускать? Они же были и будут.

такое чувство что у тебя есть лишь два состояния: все хорошо и форс мажор, делаешь все условия чтобы форс мажор просто не мог наступить и все
на простом примере: обновление бд, сначала бекап, потом колдовство, если колдовство закончилось неудачно — возврат прошлого состояния, и репорт в багтрекер, программиста вызывать не надо; аналогично решается любая ситуация

Почему же не быть гибким? Обе стороны гибкими? И выигрывать от этого

потому что не у всех полно свободного времени чтобы вот так легко прибежать когда кто-то пальцами щелкнет

Не легко и не только щелкнет.
Но тут да, более гибкие как компании так и индивидуумы, они более успешны.

Речь шла об очередном деплое, здесь нет гибкости. Как уже подметили коллеги, имел смысл в организации «дежурств», либо в подготовке проверенного рол-бек плана.

у саппорта это рабочеее время
Отлично и весь мир должен подстраиваться под рабочее время саппорта. И у кого корона?

Не морочьте голову. Для этого прописываются on call дежурства.
А также организовывается передача знаний саппорту _перед_ релизом/деплоем без всяких «ковбойских багфиксов на продакшене»

Ну вот тогда и подымается дежурный. И если он понадобился для работы в выходные/праздники, то ему потом двойной day off или что-то в таком духе.

Шанс есть. Для этого вот в таких вот очень важных проектах, на очень важных этапах, кто-то должен своей светлой головушкой понять, что нужна процедура для восстановления в случае «всё пропало».

Я также полагаю, что за эту процедуру ответственный — _не_ мидл на третьей неделе работы.

Для полноты картины, в таких вот стартапах частенько все очень сесурно, включая доступ к коду только с рабочего компа, который где-нибудь в 30км от дома этого парня.

Так а может там и нет более компетентных? Н всё же гуглы

время стоит денег, так что многие готові помочь но за х2×3 например

типа так: «мне с суппорта кто-то написал, попросил помочь и забрал весь мой выходной день, с вас 500 баксов»?

Да, получатся где-то именно такие цифры.

Ни разу в моей практике за такое не платили.
Просто когда заканчивается такая ситуация и напряжение ослабевает говорю что завтра меня не будет или появлюсь после обеда, и никто никогда не говорил против.
А потом команда делает выводы, и пытается предупредить ситуация. Или не пытается если она редкая, а предупреждение дорого стоит

Просто когда заканчивается такая ситуация и напряжение ослабевает говорю что завтра меня не будет или появлюсь после обеда, и никто никогда не говорил против.

Это значит — оплачивали, но созданием кратковременного оплачиваемого отпуска. Да, многих так устраивает. Но также многих — нет, они бы предпочли деньги, или добавить к основному отпуску.

Я бы тоже предпочел, но никто не предлагает :)

Просто когда заканчивается такая ситуация и напряжение ослабевает говорю что завтра меня не будет или появлюсь после обеда, и никто никогда не говорил против.
:) ну прямо гибкий график для компании :) когда им удобно к ним едет программист по вызову

Так наоборот тоже работает. Заболел ребенок, в аэропорт надо встретить, просто уйти раньше потому что устал или не выспался — кинул в почту что нет меня и ушел. Если срочное что то — позвонят. Плюс периодически работа из дома.
Мне идут на встречу, я иду на встречу

Так наоборот тоже работает. Заболел ребенок, в аэропорт надо встретить, просто уйти раньше потому что устал или не выспался — кинул в почту что нет меня и ушел.
гибкий график наверное в 95% айти фирм в украине — и так есть возможность уйти в любой момент и отработать потом и это уже давно нормально
Плюс периодически работа из дома.
если на секьюрность не положен болт, то это всегда запрещено

Ни одной компании не знаю в которой бы это не было разрешено.
Сейчас работаю в semiconductors, топ десятка — никаких проблем работать из дома.
Лаптоп только выданный компанией, VPN до точки (а их пара десятков по миру), и все.

Может конечно и так, типа рынок работника и получается прогибать компанию как хочешь.
Но в Австралии и США это как правило не так. И поэтому только компромиссы. Тебе свободный график, ты выручаешь компанию когда надо.

А если большой клиент сказал что у него проблемы, то просто встаешь где бы ты ни был и идешь помогать.
Компания конечно пытаетс избегать таких факапов не всех не избежишь.

Может конечно и так, типа рынок работника и получается прогибать компанию как хочешь.
что за маразм? не работать в нерабочее время это прогибать компанию по-твоему? если тебе изначально дали гибкий график, то он у тебя гибкий, если нет — твои проблемы, компромиссы никакие не нужны, если изначально условия не устраивают, значит такая работа не подходит, зачем цепляться за любую работу и лезть в ярмо?

Если есть договор о on call support то как бы да, могут и ночью позвонить, но это оплачивается. Если нет — только джентельменские договорённости. Но как бы в таком случае гарантий нет доступности

компромиссы никакие не нужны

Почему?

зачем цепляться за любую работу и лезть в ярмо?

И откуда сразу вывод про ядро? Это у вас, похоже, два состояния — или нормальная по вашим требованиям, или сразу ярмо, даже если отклонения происходят раз в год.

Какие-то проблемы, требующие нарушить обычный график и режим, бывают очень часто, и совсем на них забивать действительно плохо для работы. Вопрос лишь в объёмах допустимого перекоса. Не зря в КЗоТах всех стран есть понятие сверхурочной работы и нормы оплаты за неё.

Для свободного или полусвободного графика можно установить свои соглашения, которые устроят и работодателя, и сотрудника. Например, работа рассчитывается из 35 часов в неделю и 7 часов в рабочий день, но допустимое отклонение плюс-минус 10 часов за всё время от начала работы на должности и до плюс 2 часов в день, всё остальное — по отдельному соглашению со своим начальником. Тогда можно спокойно просочковать полдня на рыбалке, с тем, что потом это наверстать, или заранее набрать себе времени на это; и можно форсировать сотрудника на срочную работу, но не приводя его в состояние выжатого лимона, и ограниченно. Тогда начальство имеет резерв в несколько дней на то, чтобы подобрать, чем заткнуть дырку или обеспечить срочное усиление работ.

Это у вас, похоже, два состояния — или нормальная по вашим требованиям, или сразу ярмо, даже если отклонения происходят раз в год.
да, здесь их именно два, есть обязательные условия, если не обязательные, необязательные сразу отбрасываются и вот у нас 2 состояния обязательные условия выполняются и не выполняются, я не могу заменить обязательное условие пачкой необязательных
Какие-то проблемы, требующие нарушить обычный график и режим, бывают очень часто, и совсем на них забивать действительно плохо для работы. Вопрос лишь в объёмах допустимого перекоса.
прокол менеджмента, отвечать нужно только за свою работу, а не тащить якорей
Не зря в КЗоТах всех стран есть понятие сверхурочной работы и нормы оплаты за неё.
это введено чтобы ограничить компании от сверхурочных 24/7 и чтобы сотруднику оплатили эти сверхурочные, принудительные сверхурочные запрещены
необязательные сразу отбрасываются

Вот этот радикализм мне и не нравится, неважно, с чьей стороны.
Потому что бывают, например, варианты «обеспечить одно из 3 на выбор одной из сторон».

прокол менеджмента

Заранее непредставимые условия, на которые не имеет смысла залагаться.

принудительные сверхурочные запрещены

Выше некоторого объёма — да. Но в разумных пределах — почему бы и нет, если платятся?

Якщо у компанії проблеми, то йдеш працювати на компанію, де немає проблем. Бо там — більші зарплати.

Практически все топ компании давно придумали как решать эту проблему. Кроме редких исключений в головах отдельных менеджеров : allthingsd.com/...-from-home-for-employees
В сфере финансов тоже это все без проблем

Практически все топ компании давно придумали как решать эту проблему. Кроме редких исключений в головах отдельных менеджеров : allthingsd.com/...-from-home-for-employees
В сфере финансов тоже это все без проблем
практически все :) ну конечно, подавляющие большинство известных компаний не приветствует работу из дому, ты бы сначала поработал в этих компаниях, а потом говорил за них, а не ссылался на статью ноунейм автора

Ящетаю (tm), что почти нонейм «оттуда» не менее ценен, чем «эксперт» отсюда. Априори, конечно, но тут не было никаких аргументов в пользу одного из них.

Vadim Kopanev, что в вашем понимании «не приветствует»? Вы имеете ввиду на постоянном основании запрещено работать?

То что это может случиться только в крайнем случае, если у компании острой необходимости в тот день в этом не будет, то работать не разрешат

не приветствует но обеспечивает.

наш клиент и наша галера иже с ним неделю работали из дому ввиду тотального затопления физического места работы :)

на всех рабочих компах стоит ВПН и спокойно себе работаешь как будто из офиса

Никто из саппорта просто так левого девелопера поднимать не будет. Или ситуация оговорена или он поднимет менеджера.

это если на фирме лютая бюрократия и никто пальцем не пошевелит без бумажки, без бюрократии все между сотрудниками на словах решается и тогда такая ситуация легко случится

Может быть, но не встречал

Раскажи это немцам. Я как то неделю поработал в командировке с ними. 18.00 все свалили из офиса. И это правильно.

и не только немцы, но и весь цивилизованный мир

Расскажи это американцам когда чип приходит с фабрики, или когда Apple начинает вопить что у них не получается что-то.

Пффф, при чем тут корона? У меня есть свои планы, свои обязанности дома, да может я занимаюсь фрилансом в свободное время. Работа есть работа а отдых есть отдых, если меня зарание никто не предупредил то никому я ничего не должен. Я сижу пью пиво с друзьями и мне нужно срочно лететь фиксить багу потому что деплой вечером?

да ладно просто он западло сделал не по понятиям пацан.

Во первых, не нужно деплоить в конце рабочего дня. В этом суть. И это проблемы не программиста, а менеджмента.

А так да. Или оплачивайте овертайм, или в рабочее время.

Во первых, не нужно деплоить в конце рабочего дня. В этом суть.
слабо деплоить на NYSE в разгар рабочего дня?
А так да. Или оплачивайте овертайм, или в рабочее время.
Поэтому и деплоят в глубокий оффпик. Естественно за 200%.

Нужно разделять личное и рабочее время, если деплой решили делать, когда разработчик ушел домой — все на свой страх и риск.

А почему бага выявляется уже ПОСЛЕ того, как админы или суппортеры накатывают новый релиз ?

Незапланированные деплои по вечерам...может ещё и в пятницу? #bestpractices

Почему-то никто не упомянул, что причина и повод увольнения часто отличаются. Во всех трех случаях имхо именно так и есть.

Ну и еще, статья конечно не об этом, но чаще не увольняют, а сокращают: деньги закончились, все свободны. Это тоже можно отнести в ошибки менеджмента, но на самом деле просто life happens.

По сути некомпетентность — это легко можно увидеть на собеседовании. Вот халатность и негативные личные качества — сложнее, но тоже можно. Тут наверное легче определить по резюме, основываясь на том то человек в целом успешен. Например в резюме может быть череда перепрыжек с места на место с периодами в 3 месяца, а могут быть длительные проекты в компаниях с описанием что он все таки там сделал. Если совсем что-то критичное, то во многих странах общаются по телефону с несколькими предыдущими начальниками человека. У нас в Украине не принято, тем более что иногда любят хлопать дверью громко, а начальники могут и подосрать. Хотя я с таким лично не сталкивался, дверью не хлопаю и начальники были все хорошие.

Приятнее когда в резюме не написано «Java SE, Spring MVC, Hibernate» и остальные мануалы, которые прочитал кандидат, а описание что качественно он сделал. «Создал проект с нуля, а потом обеспечил успешную работу над ним команды из 10 человек», «Оптимизировал отзывчивость в проекте в 10 раз». «Занимался менторингом 8 человек, которые быстро влились в проект». «Разработал правила стиля кода для всей компании». «Пришел на проект, где не было качественного мониторинга, поднял этот вопрос и потом довел мониторинг до готовности» Разглашения секретов нету как видите, а можно сказать что вероятность уволить человека значительно ниже.

Насчет ситуации с нештатным авралом из-за бага. Мне кажется мы не знаем предистории. Если дейсвительно это не первый раз, то виноват тот кто придумал деплоить в неудачное время. Если это первый раз — например сам релиз исправляет другой критический баг в другой системе и этот релиз выкатили люди в другом часовом поясе, а этот релиз ломает все в этой системе, которая поддерживается киевским временем, то человек должен был продемонстрировать что ему не начхать на проект, ведь деньги теряются реальные прямо сейчас. Он наверное в таком случае должен был все исправить. А утром он в первую очередь должен поставить вопрос о исправлении процессов чтобы больше такого не было никогда.

Все было бы неплохо, если только немного расширить первую фразу статьи,
«Хороший программист — это не обязательно хороший сотрудник ... для данной конкретной компании, в заданном коллективе и в данный момент карьеры и жизни сотрудника».

Любое увольнение это признание ошибки менеджмента. Ну серьезно. Это как бы следует из определения. Сотрудник не появляется на рабочем месте сам. Кто-то сделал ему оффер, кто-то его привел, усадил и дал работу. Говорю по своему опыту, минимум 50% наймов в моей жизни были неудачные.

Некомпетентен? Баг в процессе техинтервью. Работает «с 9 до 5» и без души? Баг в оценке мотивации менеджером. Хорошо работал первые полгода-год и завял? Баг в системе обучения/развития команды и недоработка ПМ. И т.д.

При этом увольнение — это вполне нормальная часть работы. Хотя и не самая приятная. Все делают ошибки, и кандидаты и менеджеры. Чем раньше ее обнаружили и исправили — тем лучше для всех. Это все равно стресс и т.п. но слава богу не сегодняшнем рынке труда больше должен переживать работодатель — программист найдет себе работу без особых проблем.

Ну а теперь ложка дегтя для (некоторых) программистов.

Нет какой-то универсальной шкалы «хорошести» программиста. Типа, «вот какой хороший был программист, а менеджеры дураки не оценили». Даже самый гениальный и крутой программист может быть источником проблем. Я уж не говорю, что половина программистов имеет уровень ниже среднего (по определению).

Сотрудник должен генерировать value для компании. «Его нельзя уволить т.к. он хороший специалист» это самообман.

Мне кажется тут в какой-то мере виновата наша аутсорс-культура. Подписали контракт, «застаффили», а дальше может пройти год или два, пока заказчик разберется что ничего реально не делается. Да и в этом случае, у него может быть стимул оставить все как есть, чтобы не показать свою некомпетентность в выборе / управлении подрядчиком.

Отсюда и ложное ощущение «я пришел на работу значит я выполнил свою часть контракта» и пресловутая корона на голове. Но возможно это лишь мои домыслы. :-)

А можно с этогоместа поподробнее

Я уж не говорю, что половина программистов имеет уровень ниже среднего (по определению).

Какой уровень имеется ввиду?

Нет какой-то универсальной шкалы «хорошести» программиста. Типа, «вот какой хороший был программист, а менеджеры дураки не оценили». Даже самый гениальный и крутой программист может быть источником проблем. Я уж не говорю, что половина программистов имеет уровень ниже среднего (по определению).

Правильно ли я понимаю этот абзац, что программист получает зарплату необоснованно? В смысле неотрабатывает ее полностью?

З чого такий дивний висновок? Є докази ефективності (в економічному сенсі) ринку розробників?

Матрицю ковариації між «хорошестю» програміста і зарплатою, що він отримує, — в студію.

Між іншим оригінальний коментар мав текст «ця половина програмістів отримує зарплату менше медіани» і я відповідаю саме на нього, а не пізніші редакції.

люди не идиоты

Найкоротший анекдот.

Я десь виключив з категорії «люди» себе?

Розумна людина б не встрягала в дискусії під цим постом.

Також цікаво спостерігати як оціночна кореляція падає з 0.9 до 0.8 в процесі редагування :)

Wat? И причём тут вообще зарплата?

А как тогда нужно это понимать:

Я уж не говорю, что половина программистов имеет уровень ниже среднего (по определению).

если уровень ниже среднего, то что?
К чему Вы это писали?
Какие выводы нужно из этого сделать?

Фраза выглядит неоконченной.

Уровень профессионализма, не?

«Український розробник» (tm) міряє професіоналізм рівнем віджатої від працедавця зарплати.

Уровень ниже среднего и что дальше?
Зачем это было написано?
Какую мысль хотел донести автор?
Какой вывод из этого нужно сделать?

Думаю просто крик души человека, который хоть раз нанимал программистов :)
Но фраза не относилась к зарплате вообще никак. Даже больше: программист «ниже среднего» по совокупности характеристик (знаний, мотивации, все что угодно) может идеально подходить к определенной компании и, как ни странно, наоборот.

Думаю просто крик души человека, который хоть раз нанимал программистов :)

Вот я и пытають выяснить что это такое «крик души» или неоконченная мысль автора, например его отвлек кот, пока автор набирал пост :)

Затем, что если есть программисты с уровнем ниже среднего, не очень-то странно если кого-то из них время от времени увольняют. В дополнение к тем факторам (ошибки менеджмента, bad culture fit), которые я выше перечислил.

еще возник вопрос:

Это применимо только к программистам или к руководству (СЕО, СОО, СТО, ПМ и др.) тоже?

Мне просто интересно. Может ТОП-менеджеры это просто другая порода людей :)

Что именно? Теория вероятности применима точно. Большого опыта увольнения СЕО у меня нет, но не думаю что там ситуация принципиально отличается.

я тоже так думаю, что там ситуация очень похожа и по среднему уровню в частности.

Нормальный кстати вопрос, потому что еще неизвестно, является ли «уровень» неким числом в R, и имеет ли медиана вообще смысл :)

Звісно, «рівень розробника» не є числом. В кращому випадку, вектором в просторі з необмеженою кількістю вимірів.

Та хоч до нуля. Що ця модель буде показувати практично корисного? Чесати ЧСВ?

Это как?

Девелопери святі, за все відповідають менеджери, навіть за тимчасове падіння німбу. “Інііпьот” (tm)

оказалось — не все поняли )

Так же как и вторая половина имеет уровень выше среднего. Мухуху =).
Это как стакан — наполовину пустой или наполовину полный.

Нет это так же как и вторая половина имеет уровень не ниже среднего. Здесь именно нет слова «выше».

Наверное имелось ввиду нечто вроде цитаты Джорджа Карлина «Задумайтесь о том, насколько туп среднестатистический человек, а затем прикиньте в уме, что половина из них еще тупее.»

Не нужно угадывать что здесь имлось ввиду.
Макс уже уточнил, что подобное распределение относится и на менеджеров.
Так что есть баланс, как говорится по Сеньке и шапка :)

заказчик разберется что ничего реально не делается
Если на аутстафе/аутсорсе то разобраться ему не дадут местные манагеры ;-) Будут тянуть до последнего (так как хоть клиент и апрувит кандидата, но «продает» его ему все равно «контора», и признать что промахнулись это: а) признать, что «контора» не в состоянии на ожидаемом уровне подобрать кандидата; б) поставить под сомнение общую компетентность команды, клиент посмотрит, что тут факап — там факап, и в результате начнет искать других исполнителей; ), а лучше, объяснят, что просто не хватает ресурсов и еще парочку таких же забилят.

Если речь идёт об оценке скилла по некоторой разумной шкале, то среднее арифметическое будет выше медианы, а не ниже. И ниже среднего, соответственно, будет больше половины.

Ну типа, если мы возьмём (баги — фичи) / время, то у топовых разработчиков оно будет в разы выше, чем у середнячка. А у наихудших сильно в минус уходить не будет (иначе их на работу не возьмут).

Так я знаю определение медианы. Мой посыл в том, что для типичного распределения разработчиков (футболистов, музыкантов) она будет ниже, чем среднее арифметическое (матожидание), ибо немногие лучшие будут в разы лучше многих типичных, а худшие будут где-то около ноля. Не уверен, что могу строго это обосновать.

Ну вот если взять репутацию на стековерфлоу (тот ещё критерий, конечно, но уж не хуже строк кода в час) и взять тех, у кого она больше 101 (101 можно заработать на шару, если есть профиль на другом разделе stackexchange), медиана получается 361, а среднее — 1423.

data.stackexchange.com/...ian-reputation#resultSets

Запросы украл здесь.

а дальше может пройти год или два, пока заказчик разберется что ничего реально не делается
Справедливости ради а) программист в этом процессе не только никак не участвует но и участие его т.е. инициатива с его стороны будет прямо отрицательна для б) это и есть value компании в которую он пришёл. Программист может и рад бы попрограммить да вот «аутсорс-культура» — «ваша» а не «наша». )) Не его т.е.

И по сути таки да в этом контракте он «прошёл собеседование в т.ч. и с заказчиком и пришёл на работу» — это и есть суть «выпонил свою часть контракта». А «корона» это потому что а) есть люди которые способны на выполнение только этой части контракта и именно ими начинает таки заполняться индустрия и когда таки работать таки надо без программиста таки никак; б) даже таких людей даже на такой контракт уже приходится выискивать потому как см. п.п. «аутсорс-культура» она вообще крайне специфична в своём отношении к ресурсам-программистам и их развитию помимо указанного контракта и рост сугубо численный её более чем вполне устраивает а где ж их взять на численный то рост?

Возможно, он пишет неплохой код, его работа как раз и привела к успеху проекта, но его приходится увольнять
Вы вообще читаете что вы пишете? Алексей Коваль вы бы хоть имя скрывали. К вам после такого неадеквата кто работать-то пойдет? Только самые голодные...

Тарас, я описал реальную ситуацию. Это на самом деле довольно типичная ситация когда программист интроверт, не в состоянии работать в коллективе. Иногда такие люди пишут хороший код, иногда не очень, это в общем то некритично. Главное тут то, что человек, которого я нанял должен быть готов к тому, что если проект пойдёт не на помойку, а реально начнёт приносить прибыль, то мы можем прийти к ситуации когда один человек этот проект не тянет. И на этом этапе уже становиться важным то, насколько человек адекватен и готов работать в коллективе. Часто он не готов. Как бы я не старался как менеджер оградить человека от моральной травмы общения с другими программистами, иногда самое гуманное что я могу сделать для него и для команды в целом — уволить (и конечно же, это не приносит мне удовольствия). Потому постарался дать такой совет — даже полных интровертов надо зараннее приучать к тому, что код не является их личной собственностью, а продукт взаимодействия команды. Иначе, в ряде случаев конфликта не избежать.

Программисту-одиночке можно дать разрабатывать новый проект

И даже если нету идей по новому проекту, то легко попросить человека разрабатывать изолированый компонент системы. Опыт подсказывает что так работать быстрее чем если все программисты будут равномерно топтаться по всей кодовой базе и делать 3 митинга в день чтобы решить как именно. То что у нас называют «работой в команде». Хотя проще посмотреть на работу разработчиков linux-kernel и узнать что такое «мейнтейнер подсистемы». Это очень эффективная схема

Проблема с концентрацией специализированого опыта решается обязательным peer-review кода. В любое время если в участке кода разбирается меньше двух (трех?) людей — необходим knowledge transfer.

Программисту-одиночке можно дать разрабатывать новый проект, если у него это получается лучше, чем работать совместно.

Не всегда в небольшой компании найдётся место человеку, который уже показал себя неспособным к сотрудничеству в коллективе. Когда большой пул программистов и проектов, тогда возможно место и найдётся... А в маленькой компании со временем всё таки остаются те люди, которые умеют найти общий язык.

>80% коментов — «неправы менеджеры»
Эй, прогеры, вы своей короной потолок не цепляете? Мне интересно, что за каста у вас неприкасаемых?
я не про истории из топика, а про подход — «программисты не могут быть виноваты»

Якщо корона чіпляється — це недоробка керівництва, починаючи з офіс-менеджера. Важко було стадіон зняти для офісу, чи що?

из всех историй более-менее валидные причины только

Бывает, что человек старается, а результатов мало
и
некорректное поведение с заказчиком
но только если он пьяный нах послал заказчика, хотя тоже непонятно как это могло произойти.
Вообще складывается впечатление что во всех историях фирмы пытались сделать из говна конфетку и жутко экономили. Бабло подошло к концу — Пришлось увольнять и нашли хорошую отмазку

поднимите глазки и посмотрите на адресную строку браузера. Там должно быть что-то типа Developers Org Ua. Девелоперс, понимаете? А не Тимлидерс Орг Юа или Менеджерс Ин Юа.

В этой связи очень странно выглядит обращение

Эй, прогеры

или

каста у вас

Вы сайтом не промазали, жирненький вы наш?

я вообще-то дев в первую очередь. поэтому и позволяю себе такое панибратство

я ещё не встречал ни одного манагера, который бы не использовал этот прием. Он так и называется:

«Я вообще-то тоже программист, поэтому...»

у вас какая-то тайная обида на менеджеров?

странно, что вы не отличаете менеджеров от тим-лидов

тимлид это и есть менеджер, а то что некоторые код пишут.... ну бывает, но пишут они его хуже, чем программисты, потому что задачи другие и программировать нормально некогда уже

Зависит от определения примерно так же, как и «синьорство». Мне, например, пока попадались только кодящие тимлиды, при чем обычно они же ревьювят, анализируют бизнес требования, приводят заказчика к правильной формулировке желаний, и наставляют растущих коллег. То биш, senior c повышенным уровнем требований, обязанностей, и получений по шапке.

нужно смотреть правде в глаза, совместить в себе две профессии сложно, с противоположными целями еще сложнее, итого хороших лидов совместивших эти два качества единицы, у большинства из нас есть тимлид и часто он тоже пишет код, не могут они все быть теми самыми редкими успешными совместителями двух профессий, итого у одной части недопрограммист-менеджер, у другой программист-недоменеджер, к сожалению еще есть недопрограммист-недоменеджер, но обычно такие только по айти-притонам
если себя кто-то менеджером на должности лида не считает, то зачастую это именно программист-недоменеджер, практически самое плохое сочетание, т.к. менеджерскую часть он или не делает или делает абы как, в итоге недопонимание, технические долги, говнокод и т.д.
недопрограммист-менеджер — вот это лучший вариант для команды, и как карьерный рост — переход уже в настоящего менеджера

Я чаще всего вижу команды включающие и тимлида, как старшего/ментора/final instance в спорных моментах, и ПМа, который разруливает менеджерские задачи, имея небольшой технический бекграунд как бонус. Верю, что есть команды без одного из них (и без джуниоров, которых некому менторить?) — но пока не встречал вживую.

причем тут обида? просто кое-кто попытался самоустраниться и поиграть в трансцедентную сущность за пределами коммьюнити.

Неприкасаемые — это всякие говночисты, низшая каста. Вы точно это имели в виду?

это лишь одно из значений

>>НЕПРИКАСА́ЕМЫЙ
>>Тот, к которому нельзя прикасаться; кто не подвержен критике

Люто, бешено пригорает. Пуканы аж шкварчат. Вангую скатывание в срач и количество коментов овер 1к.

Не, тут девушек не ищут.

А чем собственно отличается увольнение программиста от увольнения любого другого исполнителя?
Есть работа. Есть ожидаемый уровень ее результата со стороны работодателя. Человек не справляется — человека увольняют.
Ожидаемый уровень результата субъективен.
Вот и все.
И менеджеров увольняют так же, как и программистов, за не достижение ожидаемого результата.

ха — survival bias.
один из клиентов одного из лидеров рынка катнул бюждет.
всё )

Разработчики виноваты никогда! Они такие какие были есть и будут. Манагеры просто надо фанатичнее относиться к работе! Например, не идти домой спать пока не найдете в команду «правильного» программиста. «Глубже» учавствовать в собеседовательных церемониях, дабы не удивляться, что взяли «неправильного».

найти нового разработчика существенно проще, чем заказчика
Нового найти может легче, а подходящего нет.

П.С. мне вот интересно: а кто откат делал если разраба уволили?

деплой на ночь глядя? деплой не протестили на полубоевом сервере? серьезно?
тимлида такого в топку отправить

Не всегда тестовый сервер в точности повторяет продакшен.
Представьте себе — несколько тысяч машин, на которые нужно задеплоить.
Все с разным железом, разным интернет-каналом. В 95% случаев код работает, оставшиеся 5% — кончилась оперативка из-за нового алгоритма, или заткнулась синхронизация из-за медленного интернета. Написавший алгоритм Вася и не в курсе, что в сети где-то остались машины с 1Gb памяти и модемами по EDGE. На дохлом тестовом сервере с 2Gb RAM все пролетело — нажимается кнопка деплоя. Это только один из бесконечного множества вариантов, зависит от проекта.

В один из поздних вечерних деплоев на продакшн
По-моему, это всё-таки о вебе. А значит никаких тысяч машин нет.
Не всегда тестовый сервер в точности повторяет продакшен.
vagrant up например

Я тоже говорю о вебе. Нет тысяч машин? Бывает, еще и как. И не только во всяких гуглах.
Пример из своего опыта. Несколько тысяч машин (кассы в аптеках), и на них деплоится веб-приложение на рельсах.
Причем тут вагрант не совсем понял, я говорил о железе и интернет канале.

Причем тут вагрант не совсем понял
Когда сервер один — можно написать конфигурацию, полностью его повторяющую.
Несколько тысяч машин (кассы в аптеках), и на них деплоится веб-приложение на рельсах
Не понимаю. Каждая касса сама себе веб-сервер?
Когда сервер один — можно написать конфигурацию, полностью его повторяющую.
А когда не один — нельзя.
Не понимаю. Каждая касса сама себе веб-сервер?
Именно так. Такая специфика. На каждой кассе отдельный веб сервер с приложением, при наличии интернета происходит синхронизация с серверами, где уже аналитика, статистика, перемещение товара и прочая фигня.

Ну, вам не повезло тогда в плане тестирования. Но тогда тем более нельзя деплоить вечером.

Мы вечером и не деплоили. Но была фигня типа «закрытие смены» — бах, баг. А ночные аптеки закрывают смены по своему графику. That’s my point, бывают проекты, где в принципе нельзя сказать «не деплоим в пятницу вечером, значит на выходных у нас точно не будет проблем».

По-моему, это всё-таки о вебе. А значит никаких тысяч машин нет.

:)

Точно тысяч машин в вебе не бывает?

Вы прекрасно поняли о каких именно «машинах» речь, не нужно выпендриваться

Igor Petruk Software Engineer в Google

В том-то и дело, что, видимо, понял

Это что-то меняет? Мы говорим о работниках, уволеных из гугля или из стартапов попроще?
Тем более, независимо от масштабов, мне сложно представить тысячу веб-серверов, каждый из которых имеет разную конфигурацию, и на каждый из которых деплоится веб-приложение. Будем реалистичными, это чаще всего не так, и поздний деплой без тестов — это тупо лень организовать процесс.

По второму случаю некоторые пишут, что программист должен был уточнить. Да, если непонятно — уточнить неплохо, но:
1) А если он думал, что всё понял? (понял неправильно, как выяснилось)
2)

В результате оказалось, что он переписал много старого кода, подтянул пачку новых библиотек.
Внезапно оказалось? Он настолько крут, что сделал это всё за один рабочий день? Отправить письмо — это, грубо говоря, до дня работы (полчаса, час, день — в зависимости от знания проекта). Почему никто не поинтересовался задержкой в исполнении простой фичи скажем на следующий день? Это уже зона ответственности непосредственного руководителя.
3) Не знаю у кого как сейчас, но несколько лет назад, когда слово «бодишоп» ещё не было популярным, мы были должны после ознакомления с заданием указать в баг-трекере эстимейт. Если он большой — расписать (час делать то, час это, час третье, полчаса тестировать). При такой системе даже при всём желании нельзя было отрефакторить полпроекта в рамках получасовой задачи. Конечно такая система имеет недостатки (некорректные эстимейты под давлением сверху приводят к напряженной ситуации), но это работает.

У меня лично возникло множество бурных эмоций, надеюсь, что не напишу лишнего.

Предлагаю топик стартеру написать ещё одну статью на ту же тему — за что увольняют менеджмент , или за что бросают компании. Ну, типа —

1) пришел в компанию, а там быдлокодеры сидят и код копипастят. Попробовал было их перевоспитать, но понял, что проще сменить компанию
2) пришел в компанию, а там по вечерам деплоятся, прямо из гит-репы. Пробовал объяснить про необходимость отлаженной процедуры деплоя из пакетов, с привлечением тестеров — не помогло. Пришлось расстаться.
3) было интересно, набросал какую-то фигню, а она стала приносить денег. Потихоньку на деньги слетелись мухи, и мне идея перестала нравиться...

считаю, что без такого поста будет как-то однобоко, чтоли

А, ещё одну статью надо, за что увольняют контент-менеджеров. Типа пришла, набросала лопатой на вентилятор, подняла резко количество комментов, а через месяц юзербейс сократился на 10%.

сократился до 10%
facepalm lol
пришел в компанию, а там по вечерам деплоятся, прямо из гит-репы.

Почему-то считается что именно в гите проблема, хотя когда так говорят то имеют ввиду деплой из бранча вроде мастера. А если деплоить из тега, предварительно протестировав этот тег, то гит — отличный способ доставки кода для деплоя на целевую машину. Если сборка недолгая, то это отлично позволяет не возиться с доставкой бинарей или каких-то jar/war файлов

проблема не в гите, вы правы. Проблема в факте сборки не на сборочнице, а на продакшене.

Сборка на продакшн машине имеет несколько аттрибутов стоимости 1) наличие инструментов и софта для сборки — обычно ничего не стоит 2) время сборки — зависит от проекта 3) расход тактов процессора на сборку — можно использовать nice 3) оперативная память для сборки — зависит от проекта. Зато есть и выигрыш — простота доставки.

Риски тоже стоимость, вы о них не упомянули. Причем это самая главная стоимость

Или к данным историям нужно было сразу (а не после всего флейма) получить отзыв по данным же фактам с другой стороны.

Почти во всех случаях присутствует вина руководсва. Если специалист действительно хорош, то:

1. Неумение руководителем корректно объяснить задачу, выразить свою мысль.
2. Проблемы с планированием проекта, а так же недостаточно высокие comunication/negotiation skills.
3. Неумение подобрать задачу под умения специалиста. Неумение организовать работу людей. Непонимание людей.

Ну и:
3.а. Если специалист не хочет выстраивать отношения с менеджером — как минимум, проблема не только в специалисте. А бывает, что вообще не в специалисте.
3.б. Если хороший специалист игнорит митинги. Проблема не в человеке, а в митингах.
3.в. Некорректное поведение с заказчиком — см. [3].
3.г. «невыполнение рабочих обязанностей». Если после такого хорошего специалиста без разъяснения обстоятельств увольняют — банальная некомпетентность руководства.

Вообще, абсолютно у каждого есть свои причуды. Идеальных людей нет, поэтому основная задача руководителя: максимально эффективно использовать сильные стороны подчиненного и минимизировать влияние слабых сторон.

Ну и подбирая человека даже при самом классном раскладе бюджета нужно выбирать не самого крутого из крутых с самым пестрым CV, а того, кто сможет выполнять поставленную задачу в определенных условиях. Если вы взяли не того — это ваша проблема, а не проблема того, кого вы взяли.

Да-да. Вот об этом я и говорю в параллельных комментах :)

Хочу обратить внимание что руководителем может быть точно такой же технарь, а те самые пресловутые soft skills говорят что нужно уметь ладить с разными людьми — даже с теми, с которыми не получается понимать друг друга с полуслова. Это конечно не отменяет того что в выстраивании отношений должны участвовать обе стороны.
Что до митингов — если бы они не нравились всему коллективу это одно, а если десяти программистам нравятся, а одиннадцатому — нет, то возможно проблема таки не в митингах.

Да точно, это все манагеры виноваты. Неэффективные. Теперь тоже буду на них валить, так проще.

Читаю комменты — грустно улыбает. Программист всегда прав, менеджер всегда неправ. Мда. Выступлю адвокатом дьявола (иначе тут это не воспримется :))

Ребят, это сильно долго не продлится. Есть два очень вероятных варианта развития событий. Либо наши славные правители-камикадзе убьют этот бизнес (в числе прочих), и рабочих мест просто не станет — либо нынешняя лавина джунов перейдет из количества в качество (и это — «страховка» на случай несбывания первого варианта) — в обоих случаях маятник на рынке труда качнется в другую сторону, и всем кто считает себя пупом земли, придется слегка попуститься в своем мировоззрении. А тракторов на всех не хватит, не питайте иллюзий. На Западе рынок тоже не резиновый, и чем ближе к насыщению, тем менее привлекательным для нашего брата он будет становиться. И это только кажется, что с годами будет легко перестроиться и начать смотреть на жизнь иначе — а без этого можно вдруг, внезапно и неожиданно, есть риск оказаться на обочине никому не нужным «непризнанным гением, которого почему-то все недооценивают»...

Конкретно по пунктам.

Случай 1.
Слишком мало деталей, чтоб судить кто прав, и упущена самая главная. А именно, что же все-таки ему было сказано на собеседовании, когда описывалось чем он должен будет заниматься?

оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик.
Программист так полагал, потому что ему так сказали на собеседовании — его задача будет рефакторить и внедрять практики, и больше ничего? На свое усмотрение, как он сам считает лучшим? Тогда упорно делать то что хочется а не то что сказано в поставленной задаче — это, возможно, один из способов коммуникации, в расчете на мудрость менеджера и его навыки психолога-воспитателя, который таким образом должен понять, что загружает человека не той работой которая ему была обещана, и человек недоволен...

Хотя немножко умнее было бы сделать задачу, но сказать менеджеру что вообще-то он слегка не таких задач ожидал, исходя из того что ему говорили на собеседовании и что он читал в профиле вакансии. А если несвойственные задачи повторяются, а профильных всё нет и нет, только расплывчатые обещания «когда-нибудь» — ну так испытательный срок — он обычно в обе стороны, надо просто уходить.

В таком случае конечно же очевидно, что человеку рассказали интересные сказки чтоб завлечь, а использовать его как было рассказано — никто не собирается. Надо уходить, не дожидаясь уволения (а оно последует обязательно, при такой политике как описано в кейсе). Либо надо подстраиваться и делать то что вменяется — если такой поворот устраивает (ну прочие условия слишком хороши, например, чтобы свалить самому).

С другой стороны, прежде чем начинать рефакторить, внедрять и переделывать, нужно в проект вникнуть. Зачастую выполнение небольших рутинных задач на первом этапе — один из неплохих способов для этого. Ну и несколько месяцев (кстати, «несколько» это сколько? 2? 3? 5? 10?), прежде чем позволить человеку вносить принципиальные изменения (тем более на свое усмотрение, ни с кем не согласовывая), в зависимости от масштаба проекта (об этом тоже ни слова) — это вполне нормально. Если человек этого не понимает — значит он не дорос до «рефакторинга и внедрения лучших практик», даже если он наизусть декламирует все талмуды от гуру рефакторинга и энциклопедически помнит все API всех фрейморков.
Ну и да, понимать что бинезс-потребности не всегда равнонаправлены с тягой к перфекционизму — тоже совсем нелишне.

В противном случае (это я к началу, о том что человеку рассказывалось при приеме на работу), это идиотизм программиста и ничего более. Хоть он семи пядей в науке кодирования и знает все-все модные фреймоврки — нахрен такого работника, который считает себя самым умным и лучше всех знающим, что нужно для проекта (тем более, если не он его начинал и подключается на поздних стадиях!), и тупо игнорит задачи, которые ему ставит руководство. Вместо того, чтобы хотя бы их обсудить, прежде чем делать не то что его попросили.

Случай 2.
а) Всё-таки, причина увольнения была — вот один раз отказался ночью бежать исправлять — и давай до свиданья — или перманентные косяки, которые известны но не исправляются (а отказ исправить свой косяк вечером — последняя капля)? Сколько времени человек был осведомлен о своем косяке и не желал (или не мог) его исправить, зная дедлайн? Это всё важные детали, на самом же деле.

б) Опять же, при приеме на работу, человек был осведомлен об овертаймах, рашах, ненормированном рабочем дне? Вознаграждение достаточно для него для таких условий? Обоюдное согласие было при достаточной информированности?

Без ответов на оба вопроса, пытаться вынести суждение — глупость.

Случай 3.
Рискую быть нудным, но снова: информации маловато. Из той пары фраз которой описан случай — вполне возможно, что тут ошибка менеджмента. Опять же, вопросы без которых трудно судить:
а) Каков объем кода написан, насколько продвинут проект, на момент возникновения ситуации? Условно говоря, человек сделал рисёч и прототип — или человек дошел до первой рабочей версии?
б) Человека не пробовали выдвинуть на лид-позиции, при расширении команды? Вплоть до PM, но вообще гармонично говорить об архитекте? Или к нему просто добавили исполнителей в горизонталь и поставили ими управлять кого-то, до того не имевшего отношения к проекту? В таком случае, разумеется, описанное поведение неизбежно, если человек не полный пофигист без амбиций — а его менеджер просто дурак.
Эти вопросы взаимосвязаны, на самом деле — в зависимости от ответов на первые по порядку, закономерны те или иные из следующих.

Ну по остальным всколь упомянутым, вообще нечего сказать, и всё по той же причине. Каждый из упомянутых кейсов, каждым читателем натягивается на свой опыт (или свои представления), при этом, конечно же, исходя из этого дорисовывается полная картина, деталями которые в описании кейса не существуют. В итоге делается суждение, которое не основано ни на чем, кроме собственной фантазии :)

Да, согласен, слишком долго позволять новичку (в проекте я имею в виду, а не джуну) вариться в собственном соку, не контроля что и как он делает — в этой детали явный фейл.

Я собственно что хотел сказать. Тут 99% комментов — «менеджеры дураки, программисты правы, PM-ы их недостаточно обхаживают и улавливают их настроения». Но может быть, не все так однозначно, на самом-то деле? Тем более если человек уже не джун, а имеет несколько лет опыта — значит тоже должен был уже научиться чему-то, кроме написания красивых строчек кода?

И в конце концов, во всех этих историях, кто пострадал-то? Дураки-менеджеры, или недопонятые гении-инфанты-программисты?

И в конце концов, во всех этих историях, кто пострадал-то? Дураки-менеджеры, или недопонятые гении-инфанты-программисты?

Менеджеры не пострадали. Пострадали программисты (нужно опять искать работу, и время зря потрачено), пострадал бизнес (фичи не выкачены вовремя, пользователи обижены). А менеджеры з/п получат, работников новых найдут, и будет у них всё хорошо.
Те же рекрутеры вообще должны радоваться увольнениям, это обеспечивает их работой.

Я не раз был и с одной и с другой стороны баррикад. И мое мнение такое, что в 99% во всех фейлах с проектами виноваты менеджеры.
Что не означает, что программистов всегда увольняют незаслуженно :)
Ответственность != вина.
Тут все обсуждали кейсы выше и в каждом просто явные фейлы руководства.
Разумеется. Поинт в том, что из обсуждения выходит, что фейлы бывают только у руководства. А программистов просто недопонимают и не так используют.
Ходим по кругу, надоело.
И в конце концов, во всех этих историях, кто пострадал-то?
Заказчик :)
Так никто тут и не поддерживает того программиста с рефакторингом, ибо нет деталей.
Хотя все обвиняют менеджеров, ибо хотя деталей всё равно нет :)
Я не про отдельные моменты (слишком долго не контролили новичка — да, про`б. Или как в одном из комментов — слишком много дали наделать неподдерживаемого говнокода одному человеку, прежде чем понадобилось выводить проект на новый уровень). Но лейтмотив всего срача — менеджеры всегда идиоты (а иногда еще и козлы), программисты в худшем случае — просто недопоняты менеджерами.

Даже странно, как еще вообще отрасль выживает при таком... Хотя как же — очевидно лишь героическими усилиями программистов, вытягивающих проекты несмотря на идиотизм завидущих менеджеров :)

Как раз судя по тому, что проект был успешен до того момента, как вмешалось руководство, — это не был говнокод. И то, что выход в прод постоянно откладывался (как я понял), это только подтверждает — пришедшие не вкурили.

Сколько релизов задеплоено до того, как вмешалось руководство? Продажи летели, или клиент n этапов принял? Или какой у Вас критерий успешности проекта?
Код, который не может сопровождать никто кроме его автора после ухода оного — говнокод, какие бы сложные задачи он не решал и как замечательно бы он не работал.
Вы путаете говнокод с неработающим или бесполезным кодом, видимо. Хотя одно повышает вероятность другого (особенно по мере нарастания codebase), это все же понятия разные, хотя частенько и пересекающиеся.

Код, который не может сопровождать никто кроме его автора после ухода оного — говнокод, какие бы сложные задачи он не решал и как замечательно бы он не работал.
Утверждение верно далеко не во всех случаях. Всё зависит от того, кто такие эти самые «никто кроме автора» и что они умеют. Часто бывает так, что код сложно сопровождать поскольку он написан излишне «кучеряво», и/или не покрыт тестами, или тесты формально есть, но реально они ничего не проверяют и/или сами содержат массу ошибок; в подобных случаях, да — дело в «говнокодовости» кода. Но может случиться и так, что эти самые «все кроме автора» — попросту underqualified. Например, не знакомы или плохо знакомы с используемыми технологиями или плохо понимают предметную область, не знают соответствующих разделов математики и т.д. и т.п... Сложности с сопровождением чужого кода возникают по разным причинам. Не всегда главная из них — низкое качество самого кода. Вообще (я уже писал об этом в другом месте), в нашем деле, если рассуждать в терминах «кто виноват», обычно сложно что-то понять. :)

Я в данном случае не занимаюсь поиском ответа на вопрос «кто виноват». Мне этот вопрос в принципе не интересен. Я просто попытался более-менее абстрактно рассмотреть все возможные случаи, когда «никто кроме автора не может сопровождать/менять его код». Всё.
Вина это менеджера или ещё кого — мне в данном случае не важно. Я всего лишь утверждаю, что вполне возможен случай, когда целая команда программистов (не обязательно плохих, может быть и вполне профессиональных) не в состоянии сопровождать код, написанный одним человеком. Причем код написан вполне хорошо и качественно (хорошо структурирован, покрыт тестами, не содержит в себе излишней сложности сверх того, что требуется самой задачей). Просто команда заточена под несколько иной круг задач. Не всегда дело именно в говнокоде. Достаточно часто имеет место тривиальным misplacement.

Всё верно. Но иногда «проще» заявить, что код — говно, и написан «с самого начала неправильно». Решение очевидно, но, как правило, предполагает неслабый объем работы и затрат. Это как раз тот случай, когда увольнять автора скорее всего было ошибкой. Дешевле было бы составить с ним протокол разногласий и договориться по каждому пункту.

Саша, разумеется, нет в нашей профессии истин непреложных и всегда верных. И случаи бывают разные. И разумеется, когда я говорил о случае «никто кроме автора не может», я НЕ имел в виду что любой джун должен разобраться в коде сеньора, иначе это говнокод — а вел речь о сопоставимых по уровню «наследниках» кода.

Причем код написан вполне хорошо и качественно (хорошо структурирован, покрыт тестами, не содержит в себе излишней сложности сверх того, что требуется самой задачей).
В таком коде человек со сходными скилами не будет иметь проблем разобраться (хотя ты не все критерии привел конечно — есть еше такие понятия как самодокументирующий код, например, но суть ясна).

Беда в том, что далеко не всегда и не все гениальные программисты способны продуцировать такой код. Зачастую код работает и выполняет архи-задачу, но разобраться в нем — невозможно, а расширять, поддерживать, исправлять — фантастика. Причем иногда даже самому его автору, по мере увеличения объема. Вот тогда это — говнокод без оговорок, даже если он работает безупречно в рамках решения изначально поставленных задач.

Почти всё так, но не совсем. Даже в одной и той же области, если уровень сложности задач достаточно высок, их, всегда можно делать многими разными способами. И далеко не всегда можно однозначно сказать, какой из способов лучше. У разных спецов могут быть разные индивидуальные предпочтения и в стиле кодирования, и в используемых инструментах/библиотеках/подходах. Это касается массы вещей, вплоть до такой тривиальной, как любимый способ форматирования кода на том или ином языке.
Кроме того, некоторые хорошо умеют «вживаться» в чужой код, другие хуже, некоторые не умеют вообще. В общем, с вариантом «это — говнокод» я могу в 100% случаев согласиться только в варианте, когда проблемы с поддержкой/расширением codebase возникают у самого автора. Тут уж, да не поспоришь. :) Да и тут на самом деле, всё зависит от того, насколько на самом деле изменились бизнес-требования. Может случиться и так, что действительно проще взять и переписать всё по новой. Особенно если код достаточно старый, а технологии уже поменялись/появились новые и т.п.
В общем, кроме совсем уж отъявленных случаев типа когда чувал едет из Запорожья в Днепропетровск с залётом на Луну, понятие «говнокод» — довольно субъективно, особенно в тех случаяе, когда он работает без ошибок и хорошо решает поставленную задачу. Как-то так...

Ребят, это сильно долго не продлится. Есть два очень вероятных варианта развития событий. Либо наши славные правители-камикадзе убьют этот бизнес (в числе прочих), и рабочих мест просто не станет — либо нынешняя лавина джунов перейдет из количества в качество (и это — «страховка» на случай несбывания первого варианта) — в обоих случаях маятник на рынке труда качнется в другую сторону, и всем кто считает себя пупом земли, придется слегка попуститься в своем мировоззрении. А тракторов на всех не хватит, не питайте иллюзий. На Западе рынок тоже не резиновый, и чем ближе к насыщению, тем менее привлекательным для нашего брата он будет становиться. И это только кажется, что с годами будет легко перестроиться и начать смотреть на жизнь иначе — а без этого можно вдруг, внезапно и неожиданно, есть риск оказаться на обочине никому не нужным «непризнанным гением, которого почему-то все недооценивают»...

А может менеджеров посчитают лишними и станут уменьшать их количество, а может пропадёт необходимость в новых проектах (всё возможное уже написали), а может Земля столкнётся с кометой и немногие выжившие вернутся к первобытно-общинному строю.

Остроумно, да. Жаль только что смысла ноль.

Как и в вашем тексте

Тракторов для менеджеров еще меньше)

хз, рынок не изучал, нет надобности :) Если буду валить — очень вероятно, с дауншифтом (вернее, вообще со сменой отрасли). Но пока что задачи иные :)

из знакомых в основном дауншифтятся до кодеров, если совсем навыки не растеряли.

Я уже слишком стар, чтобы возвращаться назад. Это будет потерей времени. Интереснее было бы попробовать что-то совсем новое. Но текущее положение вполне пока устраивает, хотя и скатывается в рутину с постоянным решением извне прилетающих проблем, что начинает утомлять.
А покодить мне и так никто не мешает периодически, для поддержания формы. Всё реже получается выделить время, правда. И форма (для кодинга) сдувается, да.
P.S. Под дауншифтингом я имел в виду не возврат назад по «карьере», или откат в молодость по финансовому положению — а скорее смену статуса, начало чего-то нового с более низкой ступени — надеюсь понятно что имеется в виду.

Может Клоуном в цирке ? Я серьезно. Дарить детям радость и смех.

Не. Производство, переработка, экотехнологии. Вот что интересно попробовать. Но в нашей стране сюда без четких связей хотя бы на городском уровне — хрен сунешься...

Программист не может быть прав или неправ. Он может только соответствовать занимаемой позиции или не соответствовать. Поставят на белаз игрушечный моторчик, а потом говорят, что моторчик-то неправ!!! Или наоборот поставят и жалуются, что он слишком прет. Манагерам стоит относится к аутсорсу как к пэт прожету с внешним финансированием, любить своих сотрудников, и проще относиться к несоответствию кого-то занимаемой должности. А не просто урывать заказчика, а потом гнобить всех кто не справится с вашими и его порывами. Подыскивайте правильных сотрудников, а не хватайте что ни попадя в попыхах, охаивая потом «подхваченное» налево и направо. То, что шуруповерт не забивает гвозди, это не означает, что шуруповерт неправ, просто найдите молоток, а шуруповерт не стоит выбрасывать — используйте его для соответствующего вида работ и будэ вам шастя :)

Программист не может быть прав или неправ. Он может только соответствовать занимаемой позиции или не соответствовать.
Вот тут согласен (если речь идет чисто о профпригодности, без всего остального мелькавшего в обсуждении)
Беда в том, что не всегда удается распознать, соответствует или нет. А бывают такие, которые очень хорошо умеют себя «продать», позволив выяснить свою реальную ценность только уже в процессе сотрудничества. Я не говорю что таких большинство или даже просто много — но встречаются дсотаточно часто, чтобы не считаться статистической погрешностью.
В общем-то, для того испытательные сроки и существуют. И если уж говорить о наличии ошибки менеджера в ситуации увольнения программиста — то полностью исключая кейсы, в которых фигурирует испытательный срок.
если речь идет чисто о профпригодности
профнепригодность — это когда декомпозицию не может сделать → как следствие не выполняет задачи.
все остальное — про соответствие проекту и его задачам.
саппорт-суровый раш с багофиксом-масштабные правки == гуру-перфекционист с замашками звезды в худшем случае, будет постоянно срывать сроки. в худшем — завалит бизнес.
research — старательный, но безынициативный середнячок просто просидит время.
и так далее.

Именно. Судя по моему опыту, украинские бодишопы (если пользоваться медицинскими аналогиями) часто напоминают больницу, где окулиста заставляют заглядывать людям с жопу, проктолог лечит психов, а психиатр — подбирает очки. А главврач постоянно орет: «Ну за что мне долб%&бы?!» А на самом деле — просто не умеет расставить людей (даже тех, которые есть) в соответствии с их квалификацией и предпочтениями. ;) Про найм — это вообще отдельная история. :) Я не утверждаю, что всегда бывает именно так, но и такое тоже далеко не редкость. :)

Блин, и почему я почти во всех случаях на стороне программиста? Прям антиреклама стартапов получилась. Ну разве что в третем как-то понять можно, но не увольнять человека надо, тем более что его знания о проекте еще пригодятся, а может на новую должность перевести или проект другой подымать.

Так програмісти ж — то святі! Вони за якісь жалюгідні $10K на місяць (після податків) готові вносити баги в код аж цілі 4 години на тиждень!

ну я допускаю неполное изложение проблемы, но в целом как-то не очень из статьи видно.

Похожая ситуация — некорректное поведение с заказчиком. По словам Сергея Немчинского, тимлида в IntroPro, если разговор об аутсорсе, то за подобные промахи людей увольняют в 24 часа. Слишком уж аутсорс зависит от заказчика. Жестоко, но вариантов нет — найти нового разработчика существенно проще, чем заказчика
Это логично, потому что outsourcing это customer service, а не software development бизнес.

Тепер пишіть статтю «Чому звільняються програмісти?».

Сам особисто звільняв програмістів виключно за дуже низьку продуктивніть і відсутність бажання вчитися.

Дуже гарний пост.

Підкажіть будь ласка метрики, за якими Ви рекомендуете оцінювати продуктивність програміста.

Вроде еще Джоэль говорил, что программистам (и не только) чёткие метрики давать опасно, потому что они будут вместо работы тупо максимизировать заданные параметры забивая на всё остальное.

Андрій вибачте будь ласка.
Мое питання було конкретно до пана Włodzimierz Rożkow

1. Способность выполнять задачи в сроки хотя бы рядом с пределами собственных оценок
2. Отсутствие повторяемости одних и тех же, известных и объясненных неоднократно, косяков
3. Способность делать мимнимальный research при возникновении технических проблем
4. ... блин думал как-то вкратце выделить главное, ну чую тут еще на полчаса можно разливаться.

Я лучше задам встречный вопрос: а по-Вашему, как-то вообще можно (и вообще, нужно) судить о продуктивности программиста? Не с точки зрения программиста — а вот для менеджера, предложите, как вы себе это видите. Ну кроме конечно вопроса «ну как, ты сегодня продуктивно поработал?» :)

Женя, по-моему полчаса — это слишком оптимистичная оценка для такой задачи. Я над ней думал не раз и не два в жизни. Сколько часов затратил — не знаю, но точно не один десяток в общей сложности. Давно уже сбился со счёта. Пока не решил. :) Ну, и потом, это ещё и от проекта очень сильно зависит. Одним нужно умение быстро выкатывать нужные фичи с «допустимым» качеством, другим (которых, к сожалению очень мало) нужно писать код, которые, если его не трогать, будет годами работать почти без ошибок. Требования на самом деле у всех разные. ;) Не существует идеального сферического программиста в вакууме.

Санек, всё это верно, если говорить о сферическом коне в вакууме. Но в конкретных проектах и конкретных кейсах, обычно все-таки можно сказать, продуктивно или нет работает человек, и как-то минимально это обосновать. Да в сравнении с остальными, хотя бы — если работает команда и делает схожие по сложности задачи. И метрики есть, более или менее применимые в каждом конкретном случае.
Человек же которому я отвечал, если я правильно его понял, хочет сказать что невозможно оценить продуктивность программиста. Хм.

Одним нужно умение быстро выкатывать нужные фичи с «допустимым» качеством, другим (которых, к сожалению очень мало) нужно писать код, которые, если его не трогать, будет годами работать почти без ошибок.
И, Саня, если для _бизнеса_ приемлемо «допустимое качество» в нужные сроки, а код, который работал бы годами, но к сожалению, стал никому не нужным, потому что гениальный перфекционист потратил на него слишком много времени, и проект умер из-за критичного срыва сроков — тогда слова «к сожалению» не всегда становятся применимыми :)

В конкретных случаях можно конечно. Только тогда эти метрики относятся не к продуктивности программиста вообще, а к его продуктивности в конкретном проекте на конкретных задачах.

Да в сравнении с остальными, хотя бы — если работает команда и делает схожие по сложности задачи. И метрики есть, более или менее применимые в каждом конкретном случае.
Да, сравнивать всегда можно. Но если Вася работает на данном проекте лучше чем Петя, это не обязательно означает, что Вася лучший программист. Возможно просто Пете лучше подошел бы совсем другой проект. Или даже просто другой круг задач в пределах того же проекта. С такой оговоркой согласен. Но тогда речь идет не столько о классе самих специалистов, сколько об их соответствии решаемым задачам. :)

Хм.
Если Васю пытаются использовать на задачах выше его квалификации — он будет менее продуктивен чем мог бы — хотят тут как раз люди и растут профессионально.
То же справедливо, если задачи сильно ниже и на постоянной основе — теряется форма и мотивация.
Если Васю используют на задачах под которые нужны другие технические скилы, чем есть у Васи — он будет менее продуктивен чем мог бы (но быстро научится, если умеет учиться)

В этих случаях менеджер либо понимает положение дел и продолжает использовать Васю as is — например, некем на данном этапе заменить, или Вася всё равно сделает это лучше других, или еще по куче возмоных причин.
Либо он передвигает Васю на другое, меняя кем-то на текущих задачах — если есть такая возможность.
Либо происходит увольнение — и вот тут может возникнуть тема чьей-то ошибки или ответственности, если увольнение происходит не по обоюдному согласию, с пониманием что Вася не на своем месте.

Но если Васю используют на технологиях его профиля, на задачах соответствующих его скилам, и он, образно говоря, тащит всех назад — тут уж, извините, его сферическая продуктивность в вакууме условных «других проектов» никого не интересует и не должна.

В целом я тоже где-то так думаю.

1. Способность выполнять задачи в сроки хотя бы рядом с пределами собственных оценок

А здесь есть еще вопрос нормативов, т.е. количество времени на выполнение задачи в третий-четвертый раз опытным специалистом.

По крайней мере так рекомендуют нормировать в АйТи — часто встречал в методичках.

маленькое уточнение по 1 пункту. Очень часто программисты дают оценку в лоб. Добавить справа контейнер для баннера — 2 часа. Программист добавил за часик и радостно потирая руки после деплоя в ожидании кофе видит, что поплыла вся верстка и теперь у него остался час на то чтобы поправить «созданные ним баги». Прошло два дня менеджер не беспокоит и девелопер пыхтит. А еще через два по офису звучит вопрос Где баннер? и ответ еще не Готов! Бльоо ты 4 дня делаешь, а говорил 2 часа! А девелопер молчит он-то перелопатил половину цсс и херачил так, что мама не горюй, сил на аргументацию не осталось. Манагер в ярости просит показать видит непереверстыша и говорит Ты все сломал я же просто просил добавить баннер, а не просил ничего переделывать! Ты уволен, я вот еще на доу напишу, что ты несоответствуешь званию нормального программиста :)

По второму пункту. Если косяки программыста постоянны то есть возможность выявить их причину. Например, джун не тянет — найдите ему более опынтного лида, который и оценку даст точную и поможет вложится в оценку, либо замените джуна более опытным человеком и потом четче поясняйте собеседователям кого хотите видеть на позиции.

Эстимейшен ресерча яркий пример для первого пункта. Программист неспособный ресерчить — первый раз слышу он же как-то нашел инфу как успешно пройти собеседование :)

4 — яркий пример того что вы не хотите разливаться и если вы так же ведете себя на своей позиции, то все ваши внутренние желания не смогут быть воплощены в жизнь, рискуя быть недонесенными.

Программиста оценить невозможно и даже не нужно. Оценивайте свой продукт. И не врите себе что виноват только программист :) Пылесос не виноват, что после уборки ковры всеравно старые :)

Т.е. он сидел днями тихо и напряженно работая, не пытаясь донести что есть огромные проблемы? Тогда он просто или очень зеленый или идиот. Компания такое будет терпеть если есть офигенные плюсы у этого человека, которые перевешивают все.

А в чем проблема потерпеть? Если человек зеленый,он что не человек? Или когда вы его брали вы думали он опытным станет? Можете конечно рассказывать про то как он косячит, но вы его взяли в команду и вы с ним работаете и это ваш косяк что он не соответствует занимаемой должности так что увольняя его вы выносите вердикт себе — вы либо зеленый либо идиот. А уволив человека которому оставалось еще полдня работы вы инициализируете процесс поиска замены который может растянуться на месяцы либо закончиться очередным зеленым таким образом вместо полдня вы потратите время на поиск нового сотрудника время на его внедрение в проект и тоже время на переверстывание а если не повезет то и переписывание всего что есть. Конфликт возникает на противоречиях ваших ожиданий и его возможностей, уволив программиста вы усугубляете противоречие ведь возможности уволенного программиста становятся равными 0, а ваши требования не изменились. Так может надо было сделать ревизию требований?!? Ведь в любом случае уже прийдется тратить время на переверстывание в любом случае продукт не готов к деплою на продакшн, к тому же программист уже на пути к решению проблему, а вы еще только о ней узнали, может надо и вам адаптироваться к новым условиям внести изменения где необходимо и дальше идти к цели?!? Манагер это не тот кто только принимает увольняет. Рассказывать про проекты которые надо на завтра можете ну так напрягитесь и расскажите кастомеру о выявленных недостатках и ходе работ над ними — или вы зеленый идиот и начнете искать коня во время переправы :)

Компания такое будет терпеть если есть офигенные плюсы у этого человека, которые перевешивают все.

Руководство должно знать, соблюдает ли данный конкретный исполнитель умение самому вовремя сообщать о том, что задача не решится, требуется изменение сроков и/или пересмотр задания. Это умение не приходит изначально (по крайней мере с нашим стилем обучения), только с опытом, требуется постоянный контроль.

Тогда он просто или очень зеленый или идиот.

В чём проблема «терпеть» очень зелёного? Если никто не будет нанимать зелёных, то не будет поступления новых кадров, или они будут крайне перекошенными в умениях и подходах.

У меня сложилось впечатление что нанимали не джуниора

Я именно и хотел сказать что или зеленый или идиот. Но вроде же нанимали не джуниора? Может я это додумал. А если наняли джуниора и отправили в свободное плавание, то идиоты с другой стороны.

Добавить справа контейнер для баннера — 2 часа.
Мы вроде бы про программистов говорим, как бы есть специфика в обсуждении кейсов, но ок, пусть в целом по IT раз так.
Если косяки программыста постоянны то есть возможность выявить их причину.
Перечитайте внимательно что я написал. Там присутствуют слова «одни и те же».
4 — яркий пример того что вы не хотите разливаться и если вы так же ведете себя на своей позиции, то все ваши внутренние желания не смогут быть воплощены в жизнь, рискуя быть недонесенными.
Вау, как всё сложно. То что я просто устал писать, слишком много и так уже времени потратил, и надоело повторяться — это предположить нереально, конечно же :) И различить эту ситуацию от жизни и работы (куда Вы экстраполируете) совсем уж сложно — тут недописав, я явно потеряю в деньгах, нанесу вред проекту, или нереализую какие-то свои желания в жизни :)
Программист добавил за часик и радостно потирая руки после деплоя в ожидании кофе видит, что поплыла вся верстка и теперь у него остался час на то чтобы поправить «созданные ним баги»
Я извиняюсь, а в чем проблема девелоперу в этот момент сообщить об этой ситуации? У менеджера тогда будет выбор, либо баннер потом добавить, либо заапрувить дальнейшее изменение верстки, либо еще что-то третье придумать. Либо верстку эту отдать кому-то другому из команды, если текущий дев загружен. Молча начинать делать лишнюю работу, особенно двухдневной длительности — ну очень «умное» решение.
Бывают случаи, когда менеджер в упор не хочет понимать изменений в сроках из-за технических моментов, это проблема менеджмента. Но если программист молчит о возникающих проблемах и сцепив зубы их фиксит, кто ж ему доктор.

На то он и зеленый чтобы допускать организационные ошибки. Никто и менеджеру не мешает подойти через два часа и узнать как дела. В крайнем случае доручить более опытным коллегам проконтролировать ход работ. А если менеджер этого не понимает то кто ж ему доктор :)

Если дев зеленый, то лид или менеджер должен более часто быть на связи с ним, это нормально. И тогда, конечно, это значительный косяк менеджера, без вопросов. Четыре дня не узнавать, что там как у джуна — это надо постараться))
В parent посте о зелености ничего не сказано, кстати. Я там зацепилась за фразу

Очень часто программисты дают оценку в лоб
. Это не очень гуд, ну или нормально, если потом человек может сообщить, что ситуация несколько поменялась. А если оценка «в лоб» и потом героическое молчание, то вот за это надо по рукам ^^
1. Способность выполнять задачи в сроки хотя бы рядом с пределами собственных оценок

Дають задачу.
— За скільки зробиш?
— Тиждень, можливо дня за 4 впораюсь.
— Треба до сьогоднішнього вечора.
— Зроблю все, що зможу.
Наступного дня.
— Скільки треба часу, щоб закінчити?
— Ще зо 2 дні.
— Ти ж обіцяв зробити за день! Я ж замовнику гарантував!

Це таке неспівпадіння сроків з власними оцінками Ви мали на увазі?

Здесь налицо неумение говорить «нет» и твердо отстаивать собственную позицию. Такой человек будет везде страдать. Четко сказал — неделя, если ничего не сломается, тогда еще больше. Четко. Не нравится — сам пидаль (это говорить необязательно, только подразумевать в уме)

Здесь налицо неумение говорить «нет» и твердо отстаивать собственную позицию.

Він озвучив свою позицію. Вона була визнана неправильною і озвучена правильна. З цього моменту його думка нікого не цікавить.
Кому, коли і з якого приводу він мав казати своє сакраментальне «Нет!».

— Зроблю все, що зможу.

Эта фраза была лишней, чтобы «сгладить» конфликт интересов. Если бы со стороны разработчика звучало четко 4 дня / неделя, то у менеджера не было бы пространства для хитрожопых поползновений.

Ця фраза була сказана вже на етапі, коли той факт, що думка розробника з цього приводу не вірна а тому нікого не цікавить, уже був остаточно встановлений і озвучений.
А у менежера жодних зазіхань і не було. Просто озвучив своє «Фе!» неприпустимо повільній роботі.
І був абсолютно правий. Якщо вам дають роботу, з якою ніхто в світі не зможе впроратись, це жодним чином не знімає з вас вини за те, що ви не впорались. Більше того, той факт, що ви не впорались, безсумнівно доводить вашу повну професійну непридатність.

+ клиническая неспособность ужиться в коллективе, было и такое, к счастью едиинично.

Це коли весь коллектив постійно квасить, а один попався непитущий?
Такого варто звільняти з формулюванням «проблеми з алгоголем».

Кинул статью своему бывшему лиду. По его мнению увольняют за:
1) Софт-скиллы и несовместимость — очень часто
2) Личная неприязнь и зависть — часто
3) Окончание проекта — часто
4) Неумение работать в команде (одиночка) — редко
5) Технически слаб — крайне редко

Логично. Если на собеседовании практически не смотрят на софт-скилы, а роль они все равно играют, то приходится все заканчивать увольнением.

просто с техническими вопросами все более менее просто, и технически некомпетентных на собеседованиях уже научились отметать. А вот с софт скилами и главное желанием и умением работать сложнее. Тут надо психологом быть, да и ошибиться есть шанс всегда.

Софт-скиллы и несовместимость — очень часто
А это как? Код не в состоянии писать или что?

То есть, менеджеров нельзя на йух посылать?

Я знаю случай, когда очень толкового программиста (который сюда захаживает, кстати говоря) уволили из-за скандала с менеджером. Но не в курсе подробностей, кто там был прав, а кто виноват — не знаю.

Скандал это всегда много много минусов в карму. Лучше не доводить, если не согласен, то конструктивно, без эмоций, не переходя на личности, только объективные доводы

Кратко записать можно кратко «добро пожаловать в мир стартапов».

Напомнило протоколы «расстрельной тройки» в 37-й год: «Виновен! Расстрелять!» и «я — начальник, ты — дурак». Т

Статья требует значительных разъяснений и очень хотелось бы послушать и другую сторону, а то черезчур однобокое освещение, аж не верится.

Разработчик, хороший технический специалист, полностью игнорировал рабочие миттинги, не предупреждал, что у него не получается присутствовать.
Может рабочие митинги (скрамы) назначали каждый раз за 5-7 минут в непредсказуемые промежутки времени и человек был на обеде или еще где-то (да, да и так тоже бывает). Или рабочие митинги — многочасовая болтовня ни о чем. Надо разбираться.

Про деплои вечером — вообще клиника, если в контракте не написано. Это ж Германия, а не Украина. Если иное не прописано в контракте (подорваться по звонку), человек работает 8 часов и идет домой. В рабочее время разберется.

невыполнение рабочих обязанностей
 А человек был извещен в какие сроки, в каком качестве он должен предоставить результаты? или должен был догадаться.

В целом странное ощущение, вначале за программистами бегают чтобы нанять, а потом на них забивают и устраивают моббинг. Зачем? Если сотрудник ценен — подскажите и изложите подробней требования, неужели сложно? Если сотрудник не ценен — не берите. А нанимать, затем строить из себя мелкого царька, надеясь что человек все угадает и будет послушным рабом — глупо.

И главное не забыть добавить «все мужыки программисты козлы».
Да-да, а то часто забывают.
Вот «все менеджеры — козлы» — никто не забывает, тут всё четко :)
А как же ЧСВ.
Вот это в точку — Вы даже, наверное, не представляете, насколько :)
Статья требует значительных разъяснений и очень хотелось бы послушать и другую сторону, а то черезчур однобокое освещение, аж не верится.
К сожалению, мне контакты уволенных программистов никто не давал, о всех рассказывали только в третьем лице (что, наверное, и правильно).
Идея статьи — показать, что бывает так и так.

Валентина, а це хороша ідея — опитати людей, яких коли-небудь звільняли, щоб вони розкрили тему з іншої сторони. Впевнений — менеджерам буде чому повчитись.

Я думаю что когда хорошего специалиста увольняют потому что он не вписывается в менеджмент — то это проблема менеджмента что они не способны найти контакт с специалистом.
А вообще страшная реальность такова что как бы вы круты не были вам могут уволить через 5 минут по не зависящим от вас причинам.

страшная реальность такова
А что в ней такого страшного?
Работа — она как отношения: вы вместе, пока вам обоим хорошо вместе. Если кому-то сильно не равится — время расставаться.
могут уволить через 5 минут по не зависящим от вас причинам
Менеджер тоже может сказать, что сотрудник может уволится за 5 минут по не зависящим от менеджера причинам.


Чтобы начать совместную работу надо согласние двух сторон, чтобы окончить — достаточно желания любой из сторон: исполнителя и/или нанимателя.

Любой человек, который нанимается на работу, нанимается временно.

Любой человек, который нанимается на работу, нанимается временно

Интересно то, что при найме менеджер, как правило, активно рассказывает о колосальных перспективах роста, о карьерных вершинах, которых можно достичь, но лишь спустя годы тесного сотрудничества.

Такого практически не бывает за пять минут. Звоночки видны очень заранее.

Я думаю что когда хорошего специалиста увольняют потому что он не вписывается в менеджмент — то это проблема менеджмента что они не способны найти контакт с специалистом.

Якщо звільнення створило проблеми, то Ви праві — то проблема меджменту.
Якщо обов’язки звільненого безболісно переклали на інших членів команди або легко знайшли йому заміну, то ні. У менежменту жодних проблем. А звільнений спеціаліст був проблемою, котру успішно вирішили.

Сотрудника уволили на третьей неделе работы
После этого компания прервала его испытательный срок.
Пришлось с ним попрощаться после испытательного срока.
за подобные промахи людей увольняют в 24 часа

Робити висновки і називати статтю “За що звільняють програмістів” на основі випробовувального періоду, це все одно що казати, що BMW-лайно, покладаючись на випадки неполадок під час першого тестування автомобіля.

На те він і випробовувальний період. А взагалі стаття написана просто, щоб розвести срач. Хоча, чому б і ні? :D

А я помню историю про программиста, которого уволили потому что он в коридоре дрочил. Правда узнали мы это после того, как его пытались выгнать из компании в которой я работал, за то что он еду из холодильников воровал...

Даже стесняюсь спросить, а еду вхолодильнике он трогал до или уже после?

Хіба що холодильник був у коридорі....

как представлю, то в коридор выходить страшно, даже чтобы к холодильнику сходить :)

«Американский пирог» смотрели? Вот это оно, видимо :)

аааа, лучший камент асчитаю

Опять личные качества, значит... А технарь, видимо, был знатный...

Алеся, перелогиньтесь.

По-моему, заголовок статьи не соответствует ее содержанию. Исходя из заголовка, статья должна была описывать косяки программистов, за которые их могут уволить, а по факту, в статье описываются косяки менеджмента, за которые выгребает программист.

В статье описаны случаи из жизни, и, мне кажется, тут не может быть единого правильного вердикта, кто прав, а кто виноват. Просто так оно было. Кто захочет, может сделать выводы

А вывод из статьи, что среди работодателей есть идиоты, что в общем-то и так всем известно
А можно я совсем чуть-чуть перефразирую? :)
А вывод из статьи, что среди работодателей ТОЖЕ есть идиоты, что в общем-то и так всем известно. А вывод из статьи, что в каждом описанном случае идиотом был кто-то.
тут не может быть единого правильного вердикта, кто прав, а кто виноват.
Именно.
Кто захочет, может сделать выводы
И это будет глупостью. Почему — в параллельных комментах я уже порасписал.

У меня один вывод — однобокое описание ситуации не позволяет сделать никаких выводов по существу.

Почему же. Статья описывает несколько конфликтных кейсов без деталей, и я бы скорее сказал, что она вообще ничего не описывает — ни в одном кейсе нельза сказать по написанному, кого же винить-то.

Вот так и тянет на поиск виноватых.
Ну поиск виноватых не я тут начинал — я упомянул в самом первом посте, что выступаю «адвокатом дъявола». А вот кто-то явно путает вину и ответственность.
Тебе, как менеджеру полезнее было обратить внимание на описанное в статье и не допускать самому подобных фейлов, а не искать виноватого.
Сие подразумевает, что я не обратил внимание, допускаю подобные фейлы, и всегда ищу на кого возложить вину. Мсье телепат и экстрасенс, настолько хорошо обо мне осведомлен что аж страшно...
Я правда подзабыл, когда мы на брудешафт пили, ну то такэ.

Чекаємо статті «За що не звільняють програмістів»
Трейлер: постійні овертайми, зарплата нижча за ринкову, жодного багу, релокейт куди завгодно і коли завгодно, знання щонайменше п’яти мов тощо.

А звільнять за те, що не миєшся (ніколи за роботою і вивченням мов) і як наслідок погано пахнеш :)

Еще один кейс, о котором стоит упомянуть — когда специалист не желает выстраивать отношения с менеджментом компании.

Вишенка на торте оказалась практически в самом конце. Менеджмент, оказывается, хочет строить отношения и ждёт инициативы от работника. Потому что мама говорила, что проявлять инициативу в отношениях — фу-фу-фу; пусть побродит, помучается, поугадывает. Самые крепкие отношения получаются если молча сидеть с загадочным видом «ах, всё опять не так!».

На самом деле очень часто инициатива в отношениях с начальством сводится к тому, что:
1. Начальство говорит — присылайте Ваши идеи.
2. Все прислали идеи. Те кто не прислал идею/предложение — получили по шапке как безинициативные либо попали в список в блокнотике.
3. Все идеи оказались ... плохими. «Умный» босс добавил неозвученный критерий в оценку идеи и на возражения, что это не было озвучено делает круглые глаза «А Вы что не знали что нужно именно так?»
4. Когда после недели споров все выдохлись, начальтсво делится откровением своей идеей
5. Все с ней соглашаются (с идеей биг босса) ибо сроки реально подпирают, а овертаймить в субботник или в воскресник никто не хочет.

Тем кому надоедает играть в такую игру, постепенно перестают присылать свои идеи и защищать их. В зависимости от проекта попадают в блокнотик на страницу «Можно увольнять. Ресурс исчерпан.»

Тоже по сути верно, но я скорее про «принцессность» менеджмента в такой подаче претензии. Пассивность, завышенная самооценка и уверенность в собственной непогрешимости. «Пусть добиваются от нас взаимности и строят отношения, остальных — уволим». Они не хотят работать и решать проблемы клиентов, они хотят в «Дом-2» и строить отношения.

Именно!
Так они и принять инициативу не хотят, вот в чем проблема. Они начинают бешенно комплексовать, когда видят кого-то, кто лучше них.

У нас колись звільнили чудака за то, що неправильно зачепив помпу на бутиль з водою)))

Просто вирішили що він не тім-плеєр. Перед тим було кілька провтиків коли робив таск і не комунікував ні з ким на рахунок того чи робить як потрібно. От потім не запиташи нікого надів помпу так що потім ніхто зняти не міг))) Це була остання крапля))

Мне вот интересно, а хоть одного менеджера / проджект менеджера / рекрутера уволили за прием на работу программиста, который так накосячил?

По сути это ошибка управления (проектом), что позволили некомпетентному человеку выполнять важные функциии... или не так?

именно, а брамбулей менеджеры не получают.

Поскольку риск ошибиться в человеке есть всегда, одно конкретное увольнение не станет упреком менеджеру (разве что там какие-нибудь исключительные обстоятельства). Менеджер, у которого увольнений много как-то слишком будет, конечно, подвергнут анализу. Но если при этом он достиг поставленных целей — тоже вряд ли будет наказан.

Интересно другое — гораздо более вероятно, что за увольнение менеджера похвалят. Умение признавать свои ошибки и пройти через неприятную процедуру увольнения, очистив команду от слабых людей — ожидаемое поведение от менеджера. Куда подозрительней, если менеджер никого не увольняет. Может, конечно, все попались правильные ребята. Но может, менеджер просто вялый и не умеет сделать нужные болезненные процедуры вовремя, чтобы предотвратить проблемы в будущем.

Поскольку риск ошибиться в человеке есть всегда
Знаете Алексей, есть такое понятие как инструктаж...и очень часто на этом этапе видно тому ли человеку поручается конкретный кусок работы.
Интересно другое — гораздо более вероятно, что за увольнение менеджера похвалят. Умение признавать свои ошибки и пройти через неприятную процедуру увольнения, очистив команду от слабых людей — ожидаемое поведение от менеджера.

И исскуство управления стоит на таких китах как: постановка задачи, делегирование и контроль.

Если пан директор накосячил с любой из вышеперечисленных функций — в результате фейл.

А наказание биг босса и его (биг босса) последующее увольнение зависит от требований и компетенций его бигбоссов. Это просто вопрос времени.

Это если в результате фейл. А если нет? Если нет, то менеджер спокойно говорит бигбоссу, что он очистил компанию от ненужных людей, поднял качество команды, сократил косты, чем придал проекту нужный вектор и достиг поставленых целей. Бигбосс улыбается, одобряет смелую стратегию, которая привела к нужным результатам.

Этот топик о в том, что программисту поручили выполнить задачу, а программист задачу завалил.

Так что по условиям именно этого топика врядле бигбосса погладят по головке. Даже если он и уволит программера, который допустил фейл.

Задач тысячи, успех один. Бигбосс не интересуется задачами, он интересуется успехом.

В данном конкретном случае есть фейл, вместо успеха :)
Конечно проще всего назначить виноватым программиста и уволить с формулировкой «не соответствует заявленной квалификации».

У меня есть живой пример, когда СТО по совместительству был дизайнером. И никак не мог запомнить размер экрана айфона и размер статус бара. Доходило до смешного: 3 экрана и на каждои статус бар разной высоты.

А работу принимал — попиксельно приколупывался :) Конечно нашелся метод и для такого хитреца...

Ага, а еще бывает так что дизайнер нарисовал, кастомер сказал что делаем все так как нарисовано, а потом оказалось, что нужно сделать так как в каком то там 100500-м билде :)))

попиксельно приколупывался
и не только.... :)))
цвета фона сравнивал, шрифты и ещё всяко разно чудил на тему чего там не так и давай ка тут и там переделаем.....хотя работа была на контрактной основе :))))

а еще бывает яркость у него на телефоне не такая :)

Ага, НашаРашаСтайл (про Славика и Димона):
@"...А еще нам акулы в море пиписьки пооткусывали...
Девченки, давайте потр@хаемся...." :)))

И исскуство управления стоит на таких китах как: постановка задачи, делегирование и контроль.
Вообще, конечно, весело наблюдать, когда об искусстве управления рассуждают люди, к управлению никогда не имевшие отношения. Ну например, те у которых позиция «Developer» :)
Интересно, это прочтение пары умных книжек делает человека столь уверенным в своих управленческих познаниях, или есть другие источники мудрости? :)

Погромисты вообще любят рассуждать о вещах, в которых ничего не смыслят. Плюнь в бодишопе и обязательно попадешь в эксперта по всем жизненным вопросам.

Ну тут совсем другой случай, у человека пять с половиной красных дипломов по экономике, и опыт управления продажами. Я жестоко ошибся, ненароком задев признанного эксперта в управлении командами.

Вообще, конечно, весело наблюдать, когда об искусстве управления рассуждают люди, к управлению никогда не имевшие отношения. Ну например, те у которых позиция «Developer» :)

Евгений если это Вы нанаписали обо мне, то немного промахнулись :)

У меня изначально экономическое образование:
красный диплом бакалавра «Менеджмент, марктетинг, предпринимательтсво», Академия труда и социальных отношений
диплом магистра (2 четверки), магистратура Экономического факультета Киевского университета имени Тараса Шевченка, «Менеджмент организаций» (это декановская кафедра)
аспирантура Национальный авиационный университет
+
механико математический факультет Киевского университета имени Тараса Шевченка, специалист «Математика»

Можете поискать меня в сети, есть достаточно следов моей «экономической» деятельности, например этот 2009 года :
www.e-xecutive.ru/...y-v-upravlenii-prodazhami

А мобайл девелопмент для меня на сегодня, это так, дауншифт, перекантоваться пока штормит :)

Так тоже бывает :)

Вау, сколько дипломов и регалий. Правда непонятно, как все они плюс «финансовые методы управления продажами», заменяют опыт управления командами и компаниями в целом, и в IT в частности. Ну то такэ, бумажки в рамочке — вот что главное, ведь это такое удобрение для ЧСВ, если пафосно перечислить :)
По изначальному посту — перечисление нескольких очевидных терминов на умняке, не очень показывает реальную осведомленность. Ну и куча теоретических знаний (даже есть у Вас двенадцать красных дипломов) не заменяет опыта.

Евгений, давайте не будем передергивать, а именно не будем брать статью по финансовому менеджменту и пытаться ее натянуть на управление персоналом, да еще и а АйТи...

Мухи отдельно, котлеты отдельно.

Изначально был Ваш агрумент:

Вообще, конечно, весело наблюдать, когда об искусстве управления рассуждают люди, к управлению никогда не имевшие отношения. Ну например, те у которых позиция «Developer» :)
Интересно, это прочтение пары умных книжек делает человека столь уверенным в своих управленческих познаниях, или есть другие источники мудрости? :)

Вот именно на это я и отписал о своем образовании.

По изначальному посту — перечисление нескольких очевидных терминов на умняке, не очень показывает реальную осведомленность. Ну и куча теоретических знаний (даже есть у Вас двенадцать красных дипломов) не заменяет опыта.

И поскольку у меня есть экономическое образование, в данном случае менеджмент, то в отличии от Вас я знаю что я пишу об управлении.

Я понимаю, что для выпускников Donetsk National Techincal University, Master, Computer Engineering некоторые слова это

По изначальному посту — перечисление нескольких очевидных терминов на умняке, не очень показывает реальную осведомленность.

без обид :)

Вы ошиблись, девелопер оказался с экономическим бекграундом. Так бывает :)

Вот именно на это я и отписал о своем образовании.
... и я им искренне восхищен, но вот в плане представления о Вашем уровне экспертизы — оно ровным счетом ничего не говорит. Вы почему-то стараетесь приравнять наличие профильного образования (=теоретических знаний, если учились хорошо и не забыли с тех пор ничего, не применяя), к пониманию и умению в управлении командами. Я не спорю что образование — это большое подспорье, но без опыта — это посто красивая бумажка в рамочке, и ничего больше.
Так что уж извините, не убедили.
Ну и да, по сравнению с
Donetsk National Techincal University, Master, Computer Engineering
...Ваше образование в области экономических наук сантиметров на 12, а то и все 15, длиннее.
Но мои 11 лет практического менеджмента — толще Ваших 0 лет опыта, думаю, на сантиметр точно. Я про команды и проекты, разумеется, а не про управление продажами (тут Вы меня съедите с потрохами, уверен — правда я и не суюсь же со своими суждениями :)) При этом они еще и подкреплены 6 годами работы по специальности до, ну и собственно лет 8-9 параллельно плотно, остальное время эвентуально — т.е. понимание, так сказать, предметной области утолщает еще на пару миллиметров.

Ну это так, раз уж Вы меряться начали :)

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Как будто наличие диплома говорит о чем то

Как будто наличие диплома говорит о чем то

В данном случае это говорит, что я что-то понимаю в управлении :)

А Ваш диплом что-то говорит? :)

Нет, не говорит. Ни в моем ни в вашем.

Понимаю, зависть :)

Чему завидовать-то? Куче бумажек в рамочках? :)
Вот у меня всего одна, и вся синенькая такая — позорище. Первую работу получить помогла — дальше пользы не приносила. :)

У меня 2 красненькие и 2 синеньких.
Все четыре помогали.

Все четыре помогали.
В управлении продажами? Или в оборачивании браузера для аппстора? Как именно они вам помогали в деятельности по предмету, который мы тут обсуждаем?

Как у вас бомбит-то

Вообще, конечно, весело наблюдать, когда об искусстве управления рассуждают люди, к управлению никогда не имевшие отношения.

А ще веселіш
— коли в ресторані обурються неїстівним супом люди, що нічого крім яєчні не готували
— коли якість доріг сварять люди, що жодного км дороги не побудували
— коли свярять залізницю за запізнення електрички на годину люди, що жодного разу не керували потягом
— коли обурюються якістю медобслуговування люди, що ні в зуб ногою в медицині
— коли поносять жек і водоканал за холодні батареї і смердючу воду в водогоні ті, хто ні дня не працювали ні водопровідником ні в теплоцентралі
— коли сварять будівельників за балкон, що обвалився, люди, що навіть сараю не побудували
— коли...
... та багато чию роботу сварять, ті хто самі краще не зроблять. Люди взагалі ідіоти, майже всі. Хоч я мабуть також не виключення. Тоді всі.

Цікаво, а хоч одного CEO звільнили за те, що в нього в компанії такі некомпетентні менеджери, які наймають на роботу програміста, який так накосячив?

По суті, це помилка управління компанією, що дозволили некомпетентній людині виконувати важливі функції... чи не так?)

Напевне, їх відправляють на пенсію з гарним бонусом, як наприклад так зробили в компанії Нокія кілька років тому :)

CEO это одна из самых рисковых работ, увольняют почаще чем девелоперов

Нет, конечно. Увольнять надо не за ошибки, а за неумение (или нежелание) их исправлять.

Мне вот интересно, а хоть одного менеджера / проджект менеджера / рекрутера уволили за прием на работу программиста, который так накосячил?
За безнадежный срыв проекта (по своей вине) — увольняли. Остальное — вопрос умения вовремя исправлять свои ошибки.

За чтение DOU в рабочее время :-)

Код ради кода
 — Человеку дали конкретную задачу. Вместо того, чтобы сделать то, что ему сказали, он начал рефакторить рабочую систему, не зная как она работает, потому, что он думал, что его для этого наняли, тут проблема даже не в наказуемости инициативы, а в том, что человек даже не спросил у начальства можно ли что-то менять со своей стороны. В итоге — баги, где багов быть не должно, и на элементарную задачу уходит гораздо больше времени. Увольнение это крайняя мера, но надо понимать, что человек проработал три недели и, по всей видимости, так и не понял, что проект, который приносит деньги — не его личная песочница, в которой можно делать что хочется.
А нам всё равно
 — Это мое любимое, у всех святой гнев по поводу «Одного из поздних вечерних деплоев». Это стартап, компания, которая пытается вылезти из полной жопы и начать зарабатывать деньги. Процессы в стартапах не то что не налажены, их не сущесвтует, я работал несколько лет в такой обстановке, пока это не стабилизировалось — были и поздние деплои, и работа ночами, и по выходным. Стартапам нужны люди, которые будут выкладываться на полную, а не те, кто хочет работать с 9 до 6. Надо смотреть на то, как компания реально работает, а не на какие-то волшебные права трудящихся и то, что менеджеры идиоты, не наладили процессы. Тут же даже не расписывали как оно докатилось до позднего деплоя, косяки одного человека запросто могут к этому привести. Надо просто приходить на работу в 12 и уходить в 6, первые полтора часа пить кофе и говорить с кем-то на кухне, следующие полтора часа смотреть картинки котов и читать реддит, с 3 до 3.15 работать, так как это пик творческой продуктивности и с 3.15 до 6 take it easy, можно поганять на ps3 в комнате отдыха. Disclaimer — я тут не кочу бочку на абстрактного человека, это просто пример того, что может означать «постоянное косячество».
Сам себе на уме
Тут вообще 0 информации, может он был нормальный мужик и его просто задавили формальностями и не прислушивались к опытному мнению, я бы и сам свалил в таком случае. Как-то слабо верится, что адекватный человек не смог ассимилироваться с нормальными рабочими процессами.
Похожая ситуация — некорректное поведение с заказчиком. По словам Сергея Немчинского, тимлида в IntroPro, если разговор об аутсорсе, то за подобные промахи людей увольняют в 24 часа. Слишком уж аутсорс зависит от заказчика. Жестоко, но вариантов нет — найти нового разработчика существенно проще, чем заказчика
Не давайте людям общаться с заказчиками, если у них мозг на это не построен. Тут на 100% вина человека, который дал программисту возможность общаться напрямую. Я бы хоть какой-то вводный курс в то, как общаться с заказчиком человеку провел.

а сотрудника волнует, что компания пытается куда-то вылезти и имеет неправильные процессы? может акции сотрудникам дают? сотрудник вообще как-то заинтересован материально в успешности компании?
сначала плачутся, что никто не хочет идти в продуктовую компанию, а на деле оказывается, что там надо ночами работать и материально это не вознаграждается. нет уж, лучше я спокойно в аутсорсе поработаю

Возможно не волнует, это хорошее замечание. Меня например мотивировали бонусами — например двоекратной зарплатой, регулярным повышениям зарплаты и прибавкой к ответственности. Если бы этого не было и мой труд не ценили, я тоже не работал бы сверхурочно.

из всего, что я встречал, на Украине овертайм и забота о проекте вознаграждается максимум выходным днем, а обычно так вообще обычно «большое человеческое спасибо! все молодцы!»

Бред. Может, это на России так (или на чем Вы там живете), и Вы по своей специфике судите? :)

А бывает так, что команда овертаймит по вечерам и на выходных за некое эфемерное спасибо, а потом ещё выслушивает претензии от начальства за то, что плохо работает и посещает рабочее место только «для галочки».

Что делать в такой ситуации? )

Затесаться начальнику в лучшие друзья, добиться доверия его семьи, соблазнить его жену и переспать с ней. Если начальник серьезно совсем не понимает что команда делает что-то в личное время и не награждается никаким образом, то он быстро растеряет свой штат. Конечно если там в штате люди с яйцами, есть ведь ребята, которым страшно менять работу и они будут все терпеть, лишь бы не терять насиженное место.

Співробітнику це оплачується тим, що в випадку успішності проекту, він зможе в резюме записати не якусь нікому не відому шарагу, а відомий успішний проект. І це йому допоможе швидше знайти роботу після того, як його звільнять через те, що він погано впишеться в команду, що значно виросла після успіху проекту.

Это стартап, компания, которая пытается вылезти из полной жопы и начать зарабатывать деньги.
И шо? Если стартап взлетит, миллион-другой кто возьмёт? Правильно, основатель и со-основатели. А деплой каждый вечер у девелоперов. Это немножко нехорошо и вызывает логичные вопросы «а чё я должен».
И вообще, не понимаю разделения стартап/нет. Есть проект, есть разработчики. Стартап это или нет, нужно просто нормально работать в размеренном темпе. А не загонять людей потому что хочется быстро подняться. Создаётся впечатление, что стартап — это когда хочется крутой модный бизнес, а денег нет.

Тут все дуже просто: Хочеш людину ганяти в режимі «стартап» — давай опціон або % від доходів або якусь частку і т.д. У всіх інших випадках розміренна робота в режимі "бодішоп"( розміренна робота з адекватними графіками, плануваннями, чітким графіком роботи і т.д. ).

Эх ) если бы вы (не вы лично, а все, кто говорит про опционы и доли) реально представляли условия их исполнения — были бы совсем другого мнения :)

Я чудово знаю, що офіційно, по документам, поняття «опціон» оформити важко, у нас майже відсутня така практика, але ніхто не забороняє на етапі «стартапу», заключити з працівником джентельменську угоду, по якій він буде мати частину в подалшому успішному бізнесі чи щось таке.
Звісно, ви можете апелювати, що в такій ситуації дуже легко надурити і нажитися на наївному програмісті, але я все ж вірю в силу слова і що якщо двоє людей про щось домовились і потисли руки, то вони хоча б спробують виконати свої обіцянки. Врешті-решт, хто захоче вести бізнес з людиною, яка не відповідає за свої слова і обманює?

Да оформить то как раз легко — это делается в месте инкорпорирования компании, и обычно это юрисдикция британского права. Другое дело, что с этим делать ) Реальность реализации этого совсем отличается от распиаренных вариантов

Тут все може бути дуже індивідуально, головне, аби людина зрозуміла, що це її продукт також. А конкретна роль і конкретний профіт може бути дуже індивідуальним, від права прийняття якихось конкретних рішень до банальної фінансової премії у випадку успішного релізу.

По поводу ситации «Сам себе на уме». Наблюдал ситуацию:
1. Чувак сам за год поднял с нуля проект — один работал сутками. Проект действительно был хорошо сделан.
2. Наняли манагеров, которые его контролировали — были случаи, 3 манагера на одного чела — пока не наняли других исполнителей.
3. Чувака не особо слушали — он перестал коммуницировать с менежментом.
4. Через пару месяцев его уволили — сам себе на уме.
5. Вновь прибывшие программисты начали переписывать проект — причины не знаю — итог: было завалено несколько релизов.
6. После нескольких заваленных релизов было принято решение, что самый первый программист неправильно писал: итог — все глобально отрефакторить.
7. За полгода рефакторинга ни одного релиза. Дальше не знаю.

Ну потому что менеджменту всегда виднее ж. Даже на тех уровнях в которые он, менеджмент, не заглядывает.

Пункты 1-4: исходя из предиката что написанное полностью верно, ситуация описана объективно, и ничего не опущено — конечно же идиотизм руководства.
Пункты 5-7: хм. А так ли хорош этот чувак, если после него никто не смог к его коду подступиться? Вполне возможно что тоже, ошибка руководства, позволившего зайти столь далеко в жопу ситуации, когда набрана критическая масса кода, бесполезного в отсутствие его автора. Но тем не менее, ставит под сомнение последнюю фразу из пункта 1. Да и все-таки, причину решения переписывать проект, для объективности знать надо бы.
Ну то есть, ошибки менеджмента налицо — но можно ли сказать, что вина в ситуации только на менеджменте? Программист, конечно же, не виноват — он просто сделал говнокод, который как-то внешне работал, но сопровождению кем-то кроме него не подлежал? Зато легко представляю себе злорадство этого неоцененного гения, мол «поделом им, вот чего они без меня стОят, теперь-то поняли чего лишились, но поздно».

Програмісти не несуть відповідальності, бо не приймають ніяких рішень. Вони приймають лише жалування :)

Нє-нє, не плутайте! Якщо програміст прийняв неправильне рішення про фічу чи багу, то відповідальність за це несе менеджер, який не пояснив, не спілкувався, не допоміг «осознати» і взагалі, їх троє на одного розробника (можливо деякі причини пропустив, тут багато накидали в коментарях)

Ну первый по шапке получит таки менеджер от более вышестоящего

А я ж про що? Девелопери — святі люди, за копійки (в $K) згодні вносити баги аж пару продуктивних годин на тиждень, а відповідальний завжди менеджер!

А я про що? Моторист Вова має отримувати більше за капітана (бо моториста «дньом с огньом», і ващщє на сусідньому кориті мені +$500 пропонують) і ні за що не відповідати, бо є капітан, помкеп і т.д.

Менеджмент с вами не согласится :)

Почему обязательно злорадство?

Потому что видал таких. Да и сам, чего скрывать, по дурной молодости имел соблазны.

Мой поинт совсем не про злорадство. Если руководство хочет сделать, чтобы проект саппортило несколько человек — надо использовать иные способы. А если заточились на одного человека — то вот и результаты. Не стоит вначале экономить на спичках.

Гм... интересно... если я правильно понял... человек написал проект с 0-я, нанял манагеров, потом наняли еще (программистов?) и потом уволили того кто собственно этот проект с 0-я написал???
Как это моголо получиться? Я не говорю что такого не может быть. Интересно что за проект?

Старая байка.
Жил-был в Одессе мужик один, Боря. Работал тихонько в конторе «Одеслифт» ремонтником, звезд с небес не хватал, но на хлеб с маслом хватало. Борю на работе любили, потому как были у него золотые руки и незлобный характер.Так бы и чинил себе Боря одесские лифты до пенсии, но вынесло его с семьей на американский берег третьей волной русской эмиграции в 197... году.

В то золотое для Америки время, советских эмигрантов в стране было мало. Поэтому в небольшой местной компании по ремонту лифтов, куда Боря пришел наниматься на работу, очень удивились. Удивились тому факту, что он из СССР, а еще больше тому, что с английским на уровне «твой моя не понимайт», он надеется получить работу.

Но работу Боря все-таки получил. Починив старый допотопный лифт в том самом здании, где находился его работодатель.. А потом несколько недель подряд Боря успешно ремонтировал лифты, за которые никто другой не хотел браться.

Хозяин Бориной конторы не мог нарадоваться новому работнику, но тут одна из диспетчеров пожаловалась хозяину, что с Борей невозможно работать:

— Он ничего не понимает по-английски, — возмущалась она, — ему невозможно ничего объяснить, ну что мне делать??

— Все очень просто, дорогая..., — был ответ, — либо вы быстро выучите русский язык, либо я вас уволю... Найти другого диспетчера — не проблема, а второго такого Бориса я найду навряд ли...

Любую историю фейла, в которой задействовано более одного человека, можно изложить так, чтобы сделать виноватым (в фейле) ЛЮБОГО из участников. А можно рассказать так, что никаких виноватых вообще не будет, зато будет понятно ПОЧЕМУ именно случился фейл. В чём было слабое место, и каким образом каждый из участников мог бы со своей стороны посодейстовать общему успеху.
К чему я всё это пишу? Статья в целом неплохая, но я бы в заголовке поменял слова «за что» на «в каких случаях». И соответственно поменял стиль изложения. Если сместить акцент с вопроса «кто виноват?» на вопрос «как избежать провала?», и рассмотреть его с точек зрения всех участников конфликта, то и пользы из статьи читатели извлекут больше, и возмущённых комментов будет немного поменьше. :) А так, да, примеры — вполне жизненные. Подход только немного однобокий.

Таки да! Поиск виноватых — совковая практика и происходит из страха без причины улететь если не выполняешь истеричных хотелок руководства. Нормальный менеджмент ищет причины, а не виноватых.
Кстати менеджмент нашей страны как раз напоминает бесконечный поиск виноватых ))

причем виноватым оказывается сотрудник, а не менеджер, который привел к такому результату! все три истории — проеб в большей степень менеджмента, чем сотрудника

все три истории — проеб в большей степень менеджмента, чем сотрудника
Обоснуйте? Обязательное условие: без фантазирования деталей которых в них нет — а исключительно исходя из написанного.

Вот ваш комментарий прекрасно иллюстрирует этот самый совковый подход — сначала найти виноватого :)

Да, я представляю себе где то на высоте в 10 000 метров, два пилота гонят друг на друга:
— Ты, козёл !
— Нет, ты !
....
Бацц....

По моему скромному мнению всё зависит от осознания коммандой, что от каждого зависит судьба проекта и что все они в одной лодке, фейл одного — это фейл всей комманды. Но если уже фейл случился, то задача «правильной» комманды приложить все усилия, что бы справиться с этой ситуацией, потом сделать разбор «полётов» только лишь с той целью, что бы больше не наступать на одни и те же грабли, а не тыкать пальцами друг на друга, мот ты во всём виноват. Человек и так понимает что он не прав, так зачем его гнобить, у него и так чувство вины, что он подвёл комманду, так ещё подливать масло в огонь.

Вы когда нибудь видели, что бы при крушеии люди винили друг друга ? Нормальные люди в критической ситуации думают как разрулить ситуацию, а не кто виноват.

Как то так.

P.S. А задача «привильных» менеджеров, тим лида и т.д. помочь комманде осознать, что они — комманда, а не 5 человек по отдельности. И дать этому чувству укрепиться.

К чему я всё это пишу? Статья в целом неплохая, но я бы в заголовке поменял слова «за что» на «в каких случаях». И соответственно поменял стиль изложения. Если сместить акцент с вопроса «кто виноват?» на вопрос «как избежать провала?», и рассмотреть его с точек зрения всех участников конфликта, то и пользы из статьи читатели извлекут больше, и возмущённых комментов будет немного поменьше. :) А так, да, примеры — вполне жизненные. Подход только немного однобокий.
Разобрать конфликт с точек зрения всех участников — тоже интересно, но сложнее найти такую ситуацию, чтобы все были готовы рассматривать ее публично в деталях и комментировать.

Тут выбран формат именно блиц-опроса менеджеров (причем я общалась именно с техническими менеджерами, которые сами в свое время работали в роли программистов). Цель статьи — донести их точку зрения. Выводы делать не берусь, тут может каждый сам для себя. Кому-то по душе подстроиться, кому-то — вести свою линию. Если человек хороший специалист и, будучи уволенным, за полчаса найдет новое место, то ему, наверное, нечего переживать.

Может, возьмите интервью у программеров на ту же тему? Народу интересно. Желающих даже неанонимно наберется, я думаю. Можно еженедельную рубрику запилить.

Если кто готов поделиться, приглашаю писать мне в личку — можно попробовать

Я подумывал стать добровольцем, но когда идея стала материализовываться, то передумал.

Потому что тема скользкая, и заработать себе минус в карму очень легко даже с самыми благими намерениями. Уверен, что и Алексей Колупаев (СТО стартапа MeinFernbus) и Алеся Батьковна из топика об укакавшемся QA имели самые чистые намерения и хотели просто поделиться опытом с сообществом. А теперь им культурному человеку руки не подать.

Как говорил классик: “Ну а згодом? Про наслідки можливі не подумать? Один лиш тільки раз і вже крадеться піздець з своєю усмішкою хижой.”

Тут ещё очень важен настрой как интервьюера так и интервьюируемого. В обсуждаемой статье он (ИМХО) совершенно неверный. Об этом говорит сам заголовок статьи. Если вместо статьи типа «смотрите, какие у нас хреновые программисты» написать аналогичную под девизом «смотрите, какие у нас хреновые менеджеры», так от этого тоже проку будет мало. Вопрос по-моему нужно ставить правильно. А именно: «Как программисту найти оптимальный для себя на данный момент проект?» или «Как менеджеру подобрать на проект именно того програмиста, который сейчас нужен?». Тогда и направление мыслей интервьюируемых будет другое. Тема «кто виноват», ИМХО не интересна в принципе.

Почти во всех случаях, когда слово предоставляется только одной стороне конфликта, да ещё и ставится вопрос «Кто виноват?», формат точнее всего называется «кидание какашками». Основа основ журналистики — рассмотрение вопроса с разных сторон и предоставление слова не только всем участникам конфликта, но и всем заинтересованным сторонам. Причем с обязательным требованием высказывать своё мнение максимально толерантно по отношению ко всем оппонентам. В противном случае получается то, что получилось сейчас, а именно срачЪ (ТМ) в комментах. Ни особой пользы от статьи, ни поддержки от аудитории. Просто очередной слив эмоций. Имхо, малополезный формат. Привлекает внимание к проблеме, но ничего не предлагает для её разрешения. Как-то так...

Ужас какой, как все трое посмели отказаться быть послушными винтиками в системе построенной гениальными менеджерами?

так в первом и втором случае не было системы

Нового сотрудника в офисе уже не было, а по телефону он сказал, что уже вечер, он отдыхает, утром придет в офис, тогда и разберется.

Угу, небось еще в пятницу дело было ?

Вместо галеры сажают в офис A-класса, вместо весла выдают ноутбук, вместо барабанщика — скрам-мастер. Элитное рабство ХХІ века все изощрение и изощрение... ©Баш

Конкретно в это ситуации сотрудник шел работать в растущий стартап и, по идее, знал, куда идет.

и, по идее, знал, куда идет.
Угу. а еще, по идее, он должен был работать 24 часа в сутки, и за миску медленных углеводов :)
Это не объективный ответ.

ну тогда конкретно в єтой ситуации менеджмент мог бы его попросить остаться в офисе до того, как задеплоят и протестируют весь функционал.

Ok, тогда озвучьте какой процент от доли в стартапе ему предложили ?

Угу, небось еще в пятницу дело было ?
Кстати, у меня так пару раз было. Правда я соглашался работать в выходные за полторы ставки.

У меня тоже, правда 1 раз :). Менеджмент принял решение залить не до конца проверенный функционал на сайт, так как овнер проекта спешил с этим делом. В итоге откат изменений + испорченные выходные. Зато после этого мой ПМ для себя поставил четкое правило — с четверга по понедельник никаких апдейтов сайта, разве что те апдейты, которые окроплены жертвенной кровью тестеров.

Нового сотрудника в офисе уже не было, а по телефону он сказал, что уже вечер, он отдыхает, утром придет в офис, тогда и разберется.
Всё правильно сделал. Удачи тебе, друг, на новом месте. Ты ничего не потерял.

знакомая ситуация: заваливание телами амбразуры. до боли знакомая ситуация, побывал в такой шкуре в т.ч. да, да — увольнение самое «то».

Похожая ситуация — некорректное поведение с заказчиком.
А с какой радости ПМ (или кто там главный на митингах) подметив первую острую ситуацию в общении не оградил программиста от заказчика?
В принципе, рекомендуется проводить митинги с заказчиком отдельно от митингов с програмистом, по возможности, конечно.
Имела чудо наблюдать похожую ситуацию, когда заказчик после такого «общения» таки вильнул хвостом и уплыл к другим. Потому в той ситуации еще хорошо разрулили)

еще программисты имеют свойство ляпнуть лишнего раньше времени

Для этого и нужен ПМ, я с вами согласен на все сто, что митинг с заказчиком должен вести исключительно ПМ.

у нас свойств полно )

ну я там сверху написал, неадекватов ПМ должен держать подальше от заказчика :)

ну когда ты заказчику говоришь то, что может иметь негтивные последствия для твоей компании, то ты не очень адекватен. Ну или у тебя плохие сойт скиллы как тут говорят. :)

ну если один программер то да, зачем ему руководитель, пусть идет сразу к заказчику

В принципе, рекомендуется проводить митинги с заказчиком отдельно от митингов с програмистом,

Я думаю, что с заказчиком максимум тимлид может общаться напрямую, потому что обычный, технический специалист будет испытывать баттхерт, чтобы высказаться, что «нельзя просто так взять и запилить эту фичу!!!» . Не факт, что этот самый баттхерт не будет испытывать и тимлид, конечно, но в виду того, что он должен быть супер-адекватным, за него переживать вряд ли стоит ))

это и имелось в виду :)

Да, но я так понимаю, это крупный аутсорс, а там любят собирать всю команду, либо ПМ с той стороны.

Да, согласна, такое тоже имеет место быть. Но даже на таких собраниях ПМ может обьяснить, чтобы разработчики запоминали или записывали их concerns и потом уже передавали ПМ-у, если вдруг он пропустил эти факты.
Самой лучшей практикой может быть так же short summary meeting, которые потом обсуждаются программистами.
В любом случае, всегда есть возможность сгладить конфликт, для этого и есть пм-ы ))

Ну проекты разные бывают. В некоторых обязательно обзение с заказчиком.
Но в целом согласен, неадекватов надо держать за ширмой менеджмента и к заказчикам не пущать.

Если разработчик неадекват, через тимвьювер замючивать просто, когда начинает гвоорить каку :))))

хуже дурака только дурак с инициативой. остальное — поправимо

В один из поздних вечерних деплоев
ОДИН ИЗ
поздних вечерних деплоев

This.

Компания на постоянной основе деплоится по вечерам, когда у сотрудников уже кончился рабочий день.

Сотрудник сказал «разбирайтесь с проблемой сами»? Нет, он сказал, что разберётся с ней в рабочее время.

Стартаперы не могут в понимание, что потребность в овертайме, да ещё и на испытательном сроке, это проблема, в первую очередь, процессов компании.

Поддерживаю, главным образом в таком случае работодатель не прав. Но все прекрасно понимают, что почти все программеры работают не официально, поэтому многие и ущемляют их права.

Ну

MeinFernbus
, вроде, в Германии, не уверен что неофициально.

«Неофициально» правильно пишется так: «частный предприниматель». Или у вас они работают именно что неофициально?
Работодатель не то, чтобы совсем не прав, как раз с ЧП расстаться несложно. А вот причины увольнений мы тут и обсуждаем.

«частный предприниматель» — это очень даже официально, заключается же договор

"почти все программеры работают неофициально"© Правда что-ли ? Это из личного опыта, или есть статистика какая ?

Деплои, связанные с даунтаймами сервиса делаются в момент минимальной нагрузки — часа в 2-4 ночи.
Любите работать с 9 до 6 и предпочитать личный комфорт комфорту своих пользователей? Enjoy the competition.

1. Такой деплой может выполнить один человек из дому, при условии что процесс налажен и релиз проверен на тестовом сервере (что можно и нужно сделать в рабочее время)
2. Каждый день деплой с даунтаймом? Круто

Плюсую. Одно дело ,когда

1. Такой деплой может выполнить один человек из дому, при условии что процесс налажен и релиз проверен

А другое дело — залили в конце рабочего дня и дергают из дому чтобы правил, и это в норме вещей

Придти и помочь. Потом рассказать что они дятлы и так делать нельзя. Если повториться, то уволиться.
Все делают ошибки, нельзя быть бескомпромиссным

В вашем утверждении видится некоторая бескомпромисность.

У человека могут быть свои причины по которым он занят в личное время. Вплоть до того, что он может быть уставшим достаточно сильно чтобы не рисковать в таком состоянии лезть в код, может выпить, может не иметь дома канала связи, и так далее. Любая работа в сверурочные это добрая воля человека, если подобное не оговаривалось в контракте. Отсутствие подобной добной воли, даже в единичном случае, вполне может быть причиной отсутствия бонуса, отказом в повышении зарплаты, но вот называть подобную ситуацию как основную причину увольнения, по меньшей мере, — странно.

Нк говоря уже о том, что, в действительно важной ситуации, адекватно объяснить важность и предложить компенсацию, это задача менеджера, и от качества выполнния менеджером этой задачи зачастую и зависит — проявит ли человек добрую волю.

Вполне возможно, что ситуация сложнее и нам что-то не договаривают, но, в таком случае, не стоило и начинать поднимать тему публично.

Мав нагоду працювати з замовником, який проводив нові деплої з 00:00 до 06:00 по Києву (час вар’ювався протягом кількох років, поки мав з ними справу). Замовник відразу обумовлював з розробниками важливість, щоб під час деплою був хоча б один представник команди, який може вирішити потенційні баги «відразу на місці». В результаті, ми організовували «чергування» — раз у спрінт виділявся один відповідальний, який знаходився онлайн.

Кілька питань.
Що заважало вам ввести подібну практику?
Чому людина повина проміняти свій запланований відпочинок на неочікуваний овертайм?
Чому ніхто з інших членів команди не був у курсі того, що новачок (!) зробив критичні (!!) зміни у конфігурації (!!!)?

В мене підозра, що імовірна проблема у вас в організації процесу (сі, рев’ю тощо), а не у працівнику.

Ваш продукт створюють люди і ви б мали бути зацікавлені у якісному їхньому відпочинку у не робочий час.

нам ще і платили за такий сапорт додатково

імовірна проблема у вас в організації процесу
Та нє то не проблема то процес такий. )) Таке буває.

И можно добавить вопрос, почему вообще разработчик конфигурировал продакшн сервер, это же работа DevOps.

А ви що, не тестите код який заливаєте? Не проганяєте юніт — тестів, не маєте Qa інженерів які роблять весь цикл тестування перед заливкою на справжній сервер? Врешті-решт, не маєте якогось примітивного тестово сервера, де це все теститься?

Якщо ви подзвонили співробітнику в 2-4 ночі, дивно, що він взагалі підняв трубку, я, наприклад, перед сном завжди ставлю на беззвучний режим телефон.

P.S. Якщо у зриві релізу(зриві деплою і т.д.) винен джуніор( або новий член команди ), то винен не джуніор.

Доречі десь була здається на Хабрі як деплоїться Букінг.ком то в них досить схожий процес. Чи може краще в лапках... Але ж працює. Так буває.

P.S. Якщо у зриві релізу(зриві деплою і т.д.) винен джуніор( або новий член команди ), то винен не джуніор.

Золоті слова :)

А вы оговаривали такие овертаймы с сотрудником? У вас предлогают за них бонусы или повышеные рейты? Сотрудник давал согласие на овертаймы при устройстве на работу?
Или был расчет на то что сотрудник в ваших глазах обязан вам чем-то и должен работать когда ему скажут т.к. он на испытательном сроке и вас «молодая, дружная команда профессионалов, интересный проект» и т.п.?

Сотрудник был в курсе такого процесса в компании? При найме ему объяснили, что может возникнуть ситуация, когда после 2-4 часов ночи понадобится сделать хотфикс? Убытки от вылезшего бага на продакшене были ниже, чем были бы убытки при коротком даунтайме для деплоя в дневное время, в рабочее время разработчиков?

И нет, с 9 до 6 работать не любим, любим работать головой.

забезпечити присутність (платну) автора змін повязаних з даунтаймом не судьба?

забезпечити присутність (платну) автора змін повязаних з даунтаймом не судьба? своїми користувачи стають після отримання долі в проекті. або хоча б опціонів

Стартап на ранней фазе — это борьба за выживание. Не ходите туда, если не готовы жертвовать своим комфортом. Там некомфортно. Ни работникам, ни менеджменту.

Вы когда нанимаете сотрудника на работу, прописываете в контракте подобные случаи?

Алексей, если подобные вещи оговорены и прописаны, то все ок.
Даже если оговаривается ненормированный график и компенсации за это (пусть для стартапа это будут не деньги, а отгулы/доля и прочее)

Но я уверен, ничего подобного не было.
UPD. А в договоре, если он был указано «обработка данных на серверах заказчика с 9 до 6»

Мне все равно, я строю продукт и компанию. Они не выживут, если не приложить все возможные силы. Я честно говорю об этом на собеседовании, никаких секретов. Кто-то может так, кто-то нет.

Так мыслят только очень малая часть людей — которые product owners в самом широком смысле, проект — их детище, без ограничения временных или рабочих рамок. Увы, в компании, даже в стартапе, после переваливания за первый десяток сотрудников, таких всегда единицы.

а что же вы забрали место работы и должность с аккаунта, стыдно?

Я не работаю там с сентября.

Я так понимаю, что, судя по тому, что баг, даже в момент минимальной нагрузки, проявлялся достаточно часто, чтобы нельзя было подождать до утра, адекватное тестирование перед поставкой, это тоже «не наш метод»?

Дядя, не путай наёмный труд и договор подряда. Если человек — наёмный сотрудник , это пользователи не его, а подрядчика.

нет! Ты — раб и должен брать такси среди ночи (или на выходных) и идти — пахать. и говорить спасибо за все «хозяину» )

Ги, і в мене є «дурна» звичка — ввечері йти додому з роботи, і до наступного робочого дня відпочивати. Хм... Де я того набрався ? :D
А якщо процес на проекті поставлений так, що ввечері ( а ще краще в пятницю ввечері ) починаються деплойменти, то це, здається мені, проблема процесу на проекті/менеджменту/вміння менеджменту донести до замовника, що в такий час люди ( оказується в аутсорсі працюють люди а не роботи ) відпочивають і деплоїти буде ідіотизмом, но уж ніяк не програміста, який і без того скорше всього ковбасив своїх 8± робочих годин...

Потому что сам стартапер работает на себя и его овертаймы очень даже понятны. А сотрудник-то работает за зарплату. Отсюда и конфликт. Ведь за овертайм не доплатят и даже не поблагодарят. Но накажут. И только сотрудник с долей в компании может аргументированно послать на**й (потому что не уволят) или не послать (потому что доля).

PS. Программисты работают ровно до тех пор, пока что-то не работает. Когда всё работает, программист не нужен. А уж кто не ошибался, тем более в проекте с нуля — пусть первый кинет в меня ссылкой. В иных проектах баги и через десять лет находят. А тут эка невидаль, альфа-версия заглючила.

Нужно диверсифицировать поставки рабочей силы, что бы не было овертаймов (нанимать из разных часовых поясов) и люди могли нормально дома отдыхать. И деплоить когда все или большая часть сотрудников на работе. Еще нужно что бы на проекте все были взаимо-заменимы.
Еще есть такое понятие как «handover», для того что бы ты не сидел до 3 ночи из за того что, что то не успеваешь. Мне нравится как делает atlassian, когда деплоит Jira, сервера переводят в maintenance по таймзонам (им можно делать заказ, типа ребята мы в это время работаем не отключайте нас в это время). А то что они деплоят когда никого нет, это сугубо их личные проблемы.

Нужно деплоймент настроить нормально, чтоб не нужно было колхозом билд выталкивать. Нужны автоматические тесты — хоть какой-то минимум... Ну и деплоймент в пятницу вечером.. да в любой день вечером это марразм и неуважение к людям.

Оно-то вроде и так, человек прав, но пускай будет прав в другом месте :) Если это стартап — это часть их бизнеса, увы, и тут либо ты в потоке либо вне его, с человеком попрощались т.к. совместное будущее — туманно.

И как бы ни была сейчас цена профессия айтишника
Надо исправить

Не треба, хай і надалі залишається цінною :)

Как по мне, основная причина увольнений — неадекватность или полная некомпетентность. Остальное — поправимо :)

Поддерживаю, только забыли уточнить чья именно неадекватность и некомпетентность. А так да — 100% правда

забыли уточнить чья именно неадекватность и некомпетентность

Это такой себе интерфейс, который может реализовать любой из обьектов как со стороны менеджмента, так и со стороны dev team :)

В результате оказалось, что он переписал много старого кода, подтянул пачку новых библиотек.
а за чуваком вообще никто не следил больше месяца что-ли? Для мидла уж как-то много написал.

Во втором случае, виноват QA и руководитель который пустил код в продакшн, да еще и как оказалось деплоем ранее. Там вообще кто-то тестировал? или принцип херак херак и в продакшн?

Сам себе на уме
Если чувак пишет хороший код и привел проект к набору нового персонала, ну дайте ему дальше писать код, что вы его превращаете в человека-оркестра. Пусть решает свои задачи которые и решал. Менеджмент явно не в этой реальности где-то был или под эффектом каких-то тренингов очередных бегал по офису.

Статья потроллить написана?

Во втором случае, виноват QA и руководитель который пустил код в продакшн, да еще и как оказалось деплоем ранее. Там вообще кто-то тестировал? или принцип херак херак и в продакшн?

ключові слова

В один из поздних вечерних деплоев на продакшн
. Сталось просто те що мало статись.
а за чуваком вообще никто не следил больше месяца что-ли?
О Вы не поверите, но бывает и так, что проект уже готов чтобы х*як и в продакшен, а там.... :)))
И тогда чувак начинает понимать что дело пахнед херосином и блеять.....ооо отпустите меня.... ибо тут нет достойных меня-я-я дартаньянофф.... :)))
Чувака отпускают.....даже денег дают в догонку.....и только после этого начинают смотреть.... а что же в проекте......а там полный пизнес :)))
И тогда начинают искать кого-то кто сможет исправить чудеса ушедшего псевдогения.... :)))
Эмоции всех кому повезло фиксить все что начудил ушедший «гений» оставлю за кадром, но факты были таковы, что «гения» СРАЗУ же взяли в другую контору, продуктовую.....

Вот не поверите, мне так повезло попасть, после другого, нету времени ругаться на него, только страдать из за кода, который был написан ранее. До того как попасть, я писал много чего, но никогда не встречалось так много багов.

Upd:
Изменил полностью точку зрения, хорошего кода не бывает, главное это никогда не фокусироваться на проблемах, а искать решения.

Спустя некоторое время встретил случай даже хуже описанного выше, но другое отношение к проблеме и поиск решения, полностью избавили от каких либо трудностей. Поэтому советую всем, посмотреть на свой проблемный код с другой стороны, если вы будете решать постепенно по 1 проблеме/багу, проблемы исчезнут и появятся перспективы даже для таких проектов.

Статья написана показать, что вот — бывает так и так. Вопрос, кто виноват, я не поднимала. Просто привела истории. Кто хочет, может сделать выводы. Я бы сделала такие:
— из первой ситуации — уточнять задание,
— из второй — идти работать в ту компанию, с которой хоть как-то совпадают ценности (если у вас цель просто работать и зарабатывать деньги — что нормальная здравая цель — то не идти в стартап),
— из третьей — учиться выстраивать отношения с людьми. Ну, или, если вы классный специалист и в случае увольнения для вас не вопрос найти новое место, то можно на это забить.

За одно собеседование узнать истинные ценности человека тяжело. Тем более, что все начитаются статей «Как пройти собеседование».
Если бы было так просто разобраться в ценностях человека, то не было б столько несчастливых браков.

Статья потроллить написана?
Да нет это вполне реальность.

в первой истории я на стороне программиста, если ему явно не было сказано об ограничениях и качестве кода, который от него ожидается (желательно на собеседовании, чтобы изначально не соглашаться) — то нечего пенять...

во второй — нейтрально, бывает, что человек просто рассчитывал на грамотный процесс, что его баги выловит умелый тестер. Иначе будет ситуация как в первой истории, чувак возится с чем-то таким, что от него не ожидают, фиксает баги, которые никто и никогда не воспроизведет, время идет, сроки срываются.

Третий — это баг менеджмента, они себе в головах попридумывали (или что чаще, где-то прочитали в умных интернетах) что все плохо, и все надо менять, и вторглись в зону комфорта человека, который на себе тянул весь проект. В конце-концов — это их решение и их ответственность, но не правильно будет ставить в вину программисту, что он не вжился в их фишечку. Менеджеры зарабатывают на свой сникерс тем, что постоянно что-то «улучшают» и контролируют, программисты тем, что кодят. Ведь никто не будет рассказывать какому-то художнику, что он должен свои картины рисовать в костюме с галстуком, при этом улыбаясь в 32 зуба — и мало кто понимает, что коддинг это тоже искусство.

Пожалуй добавлю только то что когда ты работаешь с группой людей то и ответственность за группу у тебя должна быть, особенно если ты так близко работаешь с проектом, думаю именно этот случай уже от ситуации зависит.

в какой-то мере безусловно должна, но вряд-ли там был какой-то крайний случай, и программист кидался клавиатурой в коллег (ну или что-то в таком духе). В третьей истории, грамотный менеджмент просто должен был ожидать подобного развития событий, поинтересоваться у программиста, как он видит расширение штата, попробовать вместе решить вопрос — и даже если это не вышло, не делать из этого случая поучительную историю, мол вот, всем прогерам нужно срочно экстравертировать, иначе ваших основных скилзов будет недостаточно, и вас заменит разговорчивый, беспринципный, готовый делать что скажут, даже если это неправильно.

Ведь те же менеджеры, умеют подстраиваться под клиентов, которые не сразу отвечают на письма, не особо четко ставят задачи — потому что они платят денег, а деньги не пахнут. Но — в этом случае человек платит не деньгами, а своей полезностью, результатом работы, за что компания ему предоставляет деньги.

Стоит только отметить, что зарплата обычно растет вместе с ростом soft-skills, ну и для некоторых контор коммуникации важнее чем сидеть втихаря и что-то там пилить.

коммуникации можно развивать
у нас ПМы любят сказать, что это типа аутист и мизантроп, весто того чтобы провести с ним и с новыми людьми пару митингов

во второй — нейтрально, бывает, что человек просто рассчитывал на грамотный процесс, что его баги выловит умелый тестер.
Тоесть вы хотите сказать, что это нормально — писать код, не проверяя эго на баги? Пусть кто-то другой это сделает за вас?
Понятное дело что программисты тоже люди, все мы допускаем ошибки, тут тестировщики могут помочь. Но писать код с багами и отдавать на тест( или быть не увереным в том что все корректно работает) это не правильно.

я не в курсе нюансов этих ошибок (потому и сказал, что нейтрально отношусь, ведь по разному бывает) — если реализация не проходит позитивный тесткейс и пару каких-то элементарных негативных, то это конечно же вина программиста. Если это касается к примеру бизнес-логики, то надо разобраться, кто виноват — тот, кто сформулировал условия задачи, или тот, кто по этим описаниям реализовал солюшн (очень часто самые важные условия задачи проходят под графой «само собой понятных», не требующих детализации).

Это давно все поняли, и потому есть программист, который «за деревьями не видит леса» и есть тестер, который не особо вникает в технические детали, но является продвинутым юзером этого продукта — ему проще улавливать баги, нестыковки и прочее.

писать код, не проверяя эго на баги
Автор кода никогда всех ошибок не выловит, только явные. Я думаю это связано с тем, что когда разрабатываешь что-то — представляешь некий идеальный процесс взаимодействия пользователя и программы. И проверяешь работоспособность по этому процессу. Естественно, опытный программист проверит пользовательский ввод (чтобы вместо числа строка не прилетела), но всех вариантов поведения пользователя можно и не предусмотреть.
А есть ещё баги взаимодействия новых фич со старыми, там вообще всё непредсказуемо.

Инетрессно еще бы увидеть в каком виде требования человеку ставились... — фейс ту фейс? скайп или емэйл дривен? Или качественно свою работу делать должны только программисты?

По першій історії — ну як би якщо є різні варіанти фіксу, і кардинальність змін та естимація відрізняється в рази, то чому б програмісту і самому не піти до тімліда і не уточнити. Нічого б не відпало, якби обговорив. Думаю, що просто захотів саме так зробити, бо цікавіше, ніж простий фікс зробити. А тут малознайомий код, багато невідомого, хз десь щось можна випадково поламати ще — це ж треба враховувати. На співбесіді що, можна обговорити прямо такі деталі, наскільки можна буде серйозно рефакторити старий код? так це залежить від розміру проблем конкретних. Там зазвичай обговорюється, чи новий проект, чи легасі з новими фічами, чи легасі просто з сапортом і наскільки старе і паскудне легасі, оце можна обговорити.

оказалось, что новый сотрудник регулярно косячит, но не видит в этом какого-то экстраординарного явления
А что, есть люди, которые никогда не косячат???

Даже не то, чтобы никогда, а вообще человеку свойственно косячить и в этом нет ничего экстраординарного. Понять, где именно накосячил и постараться дальше избегать — надо; пофиксить косяк — надо; волноваться и видеть экстраординарное — нафиг надо, я лучше пойду работать.

Экстраординарное например что? Календарь на год в html забитый?

Этот вопрос надо задать менеджерам. Я тут могу только поугадывать, что менеджеры решили, что косячить плохо и накосячивший чувак должен не просто проанализировать косяки, а раскаяться, пообещать больше никогда не косячить и еще как-то прочувствовать тяжесть проступка.
Короче типичные для плохого менеджмента заморочки, когда важен не результат, а ритуалы.

Если работник языком может поправить козырёк на шапке — он никогда не косячит. Он просто может красиво объяснить что косяк не его или не в нём. А если не умеет языком молоть, то «новый сотрудник регулярно косячит».

Между «регулярно» и «никогда» — 50 оттенков серого. И еще 150 оттенков в умении делать из этого выводы.

В первом случае человеку не объяснили зачем его берут на проект, во втором нужно было более опытному сотруднику поручить проводить код-ревью (git, merge-request, вы же используете vcs?), а при приеме на работу письменно подтвердить что он готов работать вне рабочие часы (ну и договорится по деньгам если нужно будет). В третьем случае согласен только с увольнением по дисциплинарным причинам, с этим у нас часто туго, а про некорректное поведение с заказчиком опять таки думаю что человеку просто не объяснили то, что в его обязанности должна входить работа с заказчиками и не выдали руководство, вы же нанимаете разработчика а не менеджера по продажам? Во всяком случае большинство таких увольнений возникают из-за менеджеров.

Ну з замовником краще не випендрюваться і тим паче не гандонить його. В ЖЕК же теж не менеджери по продажам працюють, але коли хамлять — то не приємно :)

Вы правы, но есть разные способы, я, например, перестал фрилансить и пошел в компанию потому что не хотел работать с заказчиками лично, мне комфортнее когда со мной говорит мой пм который может донести до меня информацию гораздо быстрее, правда времена меняются и теперь сами заказчики платят за насилие над головой разработчика, но это уже о другом. Когда заказчик действительно ведет себя так что не каждый это переживет, а разработчики народ гордый, то в таком случае лучше поставить между ними человека, или контролировать их общение лично.

У фрілансу, мабуть, краще уникати спілкування з замовниками напряму %) Якщо говорити про ентерпрайз або про великі компанії-замовники, то зазвичай люди з тієї сторони гарні. Я дуже багато спілкувався із замовниками з усіх кутків Європи і США і жодного разу не бачив неадеквату. Але це все були великі компанії, які платили великі гроші. І звісно, будь-який неадекват з боку розробника був би для нього останнім.

Чому розробники вважають, що вони головні на проекті я не розумію. Вони виконують 10% корисного обсягу всього проекту. Ще є сейли, BA, супорт, куа, спецпризначенці на продакшні і інші (навіть тревел агенти). Якщо ланка куа слабка, то до лампочки скікі сініорів на проекті. Так само, якщо БА вафлянув і нагородив фігні — то те, що накодять 4 архітектори, можна буде викинути. Але, якщо дев сидить за трьома РМ, то він всього цього не бачить. І думає що всі дебіли, а він молодець.

Мне всегда казалось, что разработчик не общается напрямую с заказчиком.
Особенно, если взять во внимание стереотип «программисты ассоциальны» во внимание, то разрабов нужно вообще держать подальше от заказчиков, как материю от антиматерии :)

Вы ошибаетесь, не зря от middle и выше требуется приличное владение английским, а для senior-а вообще хотят чуть ли не fluent? Потому что так можно сэкономить и на менеджере и на BA и еще попытаться понизить самооценку самого разработчика: «Пообщайся с заказчиком, пойми что он хотел, а то он недоволен....». Как в Одессе в общем, конкурс по хитрожопости в самом разгаре.

Только зачем в таком случае придумано кучу менеджерских должностей (лиды, пмы), если всё равно с заказчиком кроме программиста некому поговорить.

«А скрипач не нужен, родной» © Кин-дза-дза.

Різні бувають РМ. Кожен випадок «навіщо треба РМ/ліди» треба розбирати окремо, як і випадки в цій статті. Інколи вони не потрібні, інколи без них завал. Інколи і QA не треба і «сініор архітектори» і продакт овнери.

Говорить нужно не только с заказчиком, иногда и с конечным клиентом, у которого возникла проблема с продуктом. Это бывает нудно и неприятно, и в определенных случаях подключается 100500 мененджеров. Но в целом это полезно.

Підтримую %) Але що поганого, якщо сініор дев побуде трошки і менеджером, і БА? Як на мене, це і входить в сініорність. А не 7 років J2EE, 5 з яких багофікс самопального фрейморку.

У нас раз зі сторони замовника були...девелопери замовника. Треба було підлаштувати під них АРІ, який писався в нашому SDK. Два РМ з обох сторін тут були б безсилі %)))) А проксування інфи від дева до РМ і до дева замовника заняло б дуже багато часу.

Девелопера прибирають від спілкування з замовником, бо хто спілкується з замовником той і головний. Також, в аутсорсах девелопер може перебігти на +400 дол в інший лідер ринку. І , якщо тісно співпрацював з замовником, то завдає великої шкоди компанії, яку залишив. Тому зроблена прокся у вигляді РМ, які не так часто стрибають туди-сюди.

Взагалі, як на мене, дев не може бути сініором, якщо він не хаває домену область, в якій крутиться його проект. А в доменній області, спілкуючись із реальним замовником через три проксі у вигляді РМ, ніколи не розберешься.

Да нормально. Нам дали мнение компаний — можно обсуждать. Если бы нам попытались навязать выводы — было бы плохо, а так просто нефильтрованная информация.

Да, надо дать и второй стороне возможность оговорить себя.

как по мне самый распространеный вариант увольнения — дисциплина, не считая что проект закрыли

Часто адекватний програміст середньої руки з глибоким розумінням бізнес процесів набагато цінніший для компанії, ніж олімпіадник з прокаченим скілом вирішеня задач на алгоритми.

Только результаты собеседований не подтверждают Вашу теорию :)))

Так якраз про це і кажу.

Є люди, що показують себе круто на співбесідах в плані алгоритмів, але потім не справляються з елементарними тасками коли ми переходимо на інші рівні абстракції.

Такі люди не можуть самостійно втілити навіть маленьку фічу, не розуміють business needs клієнта/користувачів, не можуть нормально співпрацювати в команді і т.д.
Їх потрібно водити за ручку і розжовувати кожен таск.

З менеджерської точки зору такі люди — величезна проблема. І чим менша компанія — тим більший негативний імпакт вони на неї мають.

Так цель собеседования проверить скилы и посмотреть на кандидатат, там адекватность и траблсолв не проверишь :)
Поэтому и «берут» скиловых людов из соображений, что главное чтоб работу работал.... :)))
А проверить справляется чел или нет....и насколько оправдывает ожидания от него......
для этого и существует испытательный срок :)))

Я на собеседованиях люблю давать ситуацию в духе «вам нужно реализовать сервис который будет синхронизировать аккаунты пользователей из внешнего уже готового веб-сайта и делать оттуда к вам Single Sign On». Ваш сервис будет физически находиться на другом сервере, но зато вам доступен разработчик, который делал оригинальный веб-сайт и вы можете о чём-то его попросить. Дальше играю роль этого разработчика и смотрю, будет ли он пытаться решать задачу чисто технически сам, или будет совмещать с софт-скилами, просить меня реализовать какой-то API, пробросить ему доступ к базе данных и т.д.. Это по крайней мере даёт представление о том, к чему человек склонен.

Мне кажется, вам просто нравятся такие ролевые игры на собеседовании.

Очень цикаво, сколько по времени длится Ваш словесный квест ?.... :)
А я на собеседованиях смотрю на адекватность того, кто собеседует, потому как если чел трудный, понтовый и далекий от реалий, то работать в команде с таким будет товарищем то еще удовольствие и не стоит никакой таньги.
+ смотрю на сайт, чего делали и делают :)
+ смотрю на фотки офиса, потому как приехал как то к одним, а там.... едва не на улице сидят и по 10 челов в одной комнатухе :)
+ читаю отзывы
+ смотрю сколько людей потикало оттуда.... :)
По факту, иногда просто цикаво пойти посмотреть «А кто там есть» и посмотреть со стороны на собеседующего :)))

Такі люди не можуть самостійно втілити навіть маленьку фічу
А как же они код тогда пишут? Или не пишут вовсе?

Є 2 варіанти:
1.Туплять і медитують поки хтось не розжує таск на мікротаски.
2.Роблять все по-своєму.

Неистово плюсую, чувствую себя как на школьной олимпиаде попавшей в день сурка.
И пофиг что из всех в UX/UI по-нормальному разбираюсь только я, угадайте какими [тип] шишками любят бросаться :)

Разработчик, хороший технический специалист, полностью игнорировал рабочие миттинги, не предупреждал, что у него не получается присутствовать. Пришлось с ним попрощаться после испытательного срока.

За результатом, програміста звільнили, проект закрили, із зекономлених коштів менеджерам видали бонуси. Як в анекдоті.

Меня там скорее порадовало определение «специалист не желает выстраивать отношения с менеджментом компании». Вроде и понятно, что работа она не в вакууме, но с всё же многие на работу идут работать, а не выстраивать отношения. И как раз задача менеджмента — оградить от излишних отношений и дать сосредоточиться на прямых обязанностях.

Угу, программист говорит, что мне на этот скоуп нужна неделя работы, а менеджер — ну нужно постараться до вторника. Не постарался — уволили)

Ключові слова насправді «не получается присутствовать». Тобто, людина працювала, була відсутня взагалі з поважної причини або взагалі не підозрювала про «міттінг».

А это уже наши домыслы. В статье вообще детально разобранных фактов нет. «Нам сказали вот что, а вы думайте что хотите».

менеджмент компанії, мабуть, були скрам мастер і продакт овнер :D

Выстраивать отношения это тоже часть работы. Даже скилл такой имеется и оценивается на перформанс ревью. Команда есть команда.

Ага, советские продавщицы уже состарились и вышли на песию, но философия «вас много, а я одна» живее всех живых

Особенно эта философия становится занимательной когда в ходе разборок каких-либо «не явился» или там как ещё нарушил Строгий Корпоративный Регламент оказывается что на конкретном проекте десяток менеджеров штуки 2-3 тимлидов и целый 1 программист причём в какой-то момент оказывается что он во всей Строгой Корпоративной Структуре вообще 1 в принципе т.е. везде на проектах «1 программист» это он и есть а на некоторых проектах так и вообще... ))

«Ходит тут, градусником своим везде в землю тыкает, температуру измеряет... А мы тут, между прочим, отношения строим!» Снежинка, Шоу «Уральские пельмени».

Підписатись на коментарі