Comments 31
Продвинутый уровень:
Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков.
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять. А то вдруг без половины разработчиков станет проще и быстрее согласовывать и писать. А если нанять ещё 2n программистов, то можно и себе денег больше попросить, и программистов постоянно укорять: "сколько же вас надо нанять, чтобы хоть что-то делалось".
Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования).
А важную информацию, наоборот надо обсуждать только в ветвящейся переписке с постоянно меняемым списком адресатов.
Заставьте оправдываться за каждый обнаруженный на тестировании баг
Это работает только с джунами. Опытный знает, что он допускает баги. И даже уже гордится некоторыми. Продуктивнее запрещать элементы TDD и максимально усложнить процесс регистрации багов (KPI по количеству, согласование с QA на заведение багов, массовое внесение инцидентов, как багов — тут много приёмов)
Отличная встряска — задержка зарплаты.
На нынешнем рынке труда — слишком одноразовый приём. Лучше намекать на премию, но не платить. Главное — премия должна быть максимально непредсказуемой.
формулируйте ТЗ как можно короче.
С тем же успехом — как можно длиннее. Круто кинуть в разработчика 400-страничной спекой: "Оцени наши доработки в проекте". Наши доработки — это изменение XML схемы, которое следует из требований одного абзаца на странице 324.
Если вы хотите обновить технологический стек, подумайте: чем новее технология, тем она сомнительнее
С тем же успехом можно менять стек каждые полгода-год.
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять
У меня был печальный опыт. На спокойный (слегка подгорающий, как и всегда) проект на 5 разработчиков руководство добавило усиление — «hot house team», как они ее гордо называли. Это такая группа «экстренного» реагирования, состоящая из ~20 бравых работников скайпа и клавиатуры.
Не знаю как они там нам должны были помочь, но работу парализовали знатно. Пару дней долбали, настраивая окружение (по очереди, естественно), пару дней бомбили вопросами, потом заставляли нас вмержить PRы в срочном порядке, с эскалацией к менеджерам и звонками на мобилу. Фиксили баги туда-сюда по четрые раза, ломая все вкруг.
Через 10 дней ада они покинули поле боя… чтобы зажигать на новом проекте.
Вот человек пишет:
Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!
Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.
И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше.
Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
Понятно, что это вечная тема для холивара.
Если он взял команду, которую собрали «с бору по сосенке», в сроки рассчитывал по команде, которая 10 соответствующих проектов сделали вместе (без текучки кадров). Ну тогда не надо удивятся, что его компетентность ставят под сомнение.
Треугольник (время, ресурсы, сроки) никто не отменял. И правильную оценку рисков то же.
А так да. Манагеры никогда не ошибаются, т.к. ничего не делают. :-)
Классно) Не везде уловил сарказм, но основной посыл понял. Жду поста с вредными советами для разработчиков!
Типа
1) НИКОГДА! НИКОГДА ни при каких условиях не писать тесты, тем более unit-тесты
2) НИКОГДА! НИКОГДА не использовать стандартные библиотеки для работы. ВСЕГДА писать свою имплементацию. Как минимум ОБЯЗАТЕЛЬНО должны быть реализована своя коллекция и HashMap
3) НИКОГДА! НИКОГДА не использовать системы контроля версий.
4) НИКОГДА! НИКОГДА не рефактрить код.
5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
6) ВСЕГДА (ОБЯЗАТЕЛЬНО), весь код должен быть в одном файле/классе
7) ВСЕГДА (ОБЯЗАТЕЛЬНО) использовать кодогенерацию SQL-запросов в виде конкатенации строк
8) ОБЯЗАТЕЛЬНО для интеграции с внешними системами для полей использовать только один тип String/char[]. Для даты написать свой парсер.
9) Документация для слабаков.
10) В название классов, функций и полей использовать как можно больше сокращений и не документированных умолчаний
11) Комментировать таблицы и поля в БД не нужно. В названиях таблиц и полей использовать сокращения и названия типа tmp1, tmp2, table1, table2 и т.д.
12) Все п-сы, а ты Д`артаньян
5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
Можно поподробнее?
if(...) {
} else if(...) {
} else if(...) {
....
} else {
}
Видел в одном проекте такую конструкцию ~ 1000 строк и ~100 условий.
Аналогично для switch/case не встречал правда.
Но теоретически ничто не мешает это сделать.
:-)
Но в этом «вредном совете» говорится, что использование как case
, так и elseif
— плохо. А что тогда?
Не обязательно, что она есть.
Но если при дополнении/изменении требований количество блоков в операторах увеличивается, то точно этот код надо рефакторить.
Можно где-то подробнее про это почитать? Почему, что не так со switch/case, чем вредно и каким образом рефакторить?
Вот конкретно такие ифы — плохо? Если эти хорошо, то какие плохо? Если эти плохо, то как быть?
Например вот из «прекрасного»
if(ro instanceof PPPlanItem) {
PPPlanItem ppRO = (PPPlanItem) ro;
if(ppRO.getSource() == 2)
result = prefix + "oebs/showpoint/" + ppRO.getPlanNo();
else if (ppRO.getSource() == -1)
result = "";
else
result = prefix + "plans/show_point/" + ((PPPlanItem) ro).getPlanNo();
} else
if(ro instanceof PPContractHeader) {
PPContractHeader ppcRO = (PPContractHeader) ro;
if(ppcRO.getSource() == null || ppcRO.getSource() != -1){
if(ppcRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1)
result = prefix + "oebs/showagreement/" + ((PPContractHeader) ro).getNumber();
else
result = prefix + "agreements/show/" + ((PPContractHeader) ro).getNumber();
}
} else
if(ro instanceof PPAdvertisementHeader) {
PPAdvertisementHeader pRO = (PPAdvertisementHeader) ro;
if(pRO.getSource() == null || pRO.getSource() != -1){
if(pRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1
|| pRO.getProcurementMethod().indexOf("Из одного источника посредством электронных закупок") > -1)
result = prefix + "oebs/showbuy/" + pRO.getNumber();
else
if(pRO.getProcurementMethod().toUpperCase().indexOf("АУКЦИОН") > -1)
result = prefix + "oebs/showauc/" + pRO.getNumber();
else
result = prefix + "publictrade/showbuy/" + pRO.getNumber();
}
} else if(ro instanceof ExpenditurePayment){
result = ((ExpenditurePayment) ro).getPaymentId() + ", " + ((ExpenditurePayment) ro).getPaymentNumber();
}
Смеялся в голос, хотя подняты далеко не смешные темы. К сожалению, некоторое число работодателей совершенно не увидит сарказма в этой статье, и чем дальше от столицы, тем это число больше.
И, самое главное, ещё один плохой совет — "написали же вы прошлый проект, хотя ТЗ раз двадцать поменяли? Значит и без ТЗ сможете!".
Ещё стоит занижать стоимость разработки перед клиентом, чтобы конкурировать с условными "Рога и копыта", тогда разработчикам нужно будет действительно в 2-3 раза быстрее согласованного делать задачи
Вредные советы работодателю. Как “правильно” взаимодействовать с разработчиком