Comments 40
Ничего не понял, но очень интересно!
А в декабре бизнес сказал, что мы должны запуститься через месяц.
Интересно, вот если я приду например на стройку, стукну кулаком по столу и скажу "всё должно быть сделано через месяц, а не три"... там все послушно гривами закивают и побегут делать за месяц, или айтишники в этом плане уникальны?
Это так и работает
Не работает. Буду послан найух, потому что срок сдачи XX/YY. И будут правы.
Работает-работает, просто кулаком стукнули чуть раньше, когда срок сдачи XX/YY ставили. Собственно отсюда (в том числе) и вечные переносы реальных сроков сдачи строек.
просто кулаком стукнули чуть раньше, когда срок сдачи XX/YY ставили.
Ну так тогда какие претензии? А в вышеописанной истории "бизнес", похоже, в одностороннем порядке поменял сроки, и ничего ему за это не было.
Ну как бы да, сначала заказчик "в одностороннем порядке" ставит срок завершения стройки в привязке к какой-нибудь памятной дате (чемпионату мира там, или дню рождения гендира заказчика), а потом исполнитель "в одностороннем порядке" сдает позже. Или не сдает вообще. А претензии - там по-разному бывает. :)
За реальные переносы строек можно нехило так на неустойку попасть. Так что стараются всё-таки достижимые в договоре ставить.
Да, на стройке все тоже самое, только матом.
вы никогда заброшенные стройки посреди города не видели?
Эт вот как раз те, что не успели за месяц... а на три у них денег уже не было...
Нет, не уникальны. Если есть доказательство что "вон те парни высотники с Китайской бригады/Электрики говорящие на позорном (этом...) язычке/ или же Арабские ребята, сделают за месяц, то... Будут работать они. И инженеру(рам) стройки с
этим работать ( НО, все может быть и на оборот, по чисто техническим/нетворкерским/софтскильным причинам, которых масса). Если что, реальные кейсы в Израиле...
Причем, ×3, работа ночью с фарой на кране, работа в ураган, работа без жратвы, работа еженедельной ( причем разной) возможностью погибнуть ( мой случай ((: )еще не предел, программисты в
"наши"*.
Все что кажеться "не так", обычно ошибка выжившего, в очень слаженных бригадах. Которые, реально заняли теплые, но уже х3 по умолчанию места. И им "кажеться", что у всех так.
В доказательство, что не согласные с утверждениями выше, из этой категории: у них на столько грамотно развито планирование, что есть время писать/просвещать на этом сайте...
Доказательство 2: кто-то обращал внимание, на сколько быстро строят в некоторых странах ( ели успевает бетон просыхать), и медленно в других? И не всегда из-за внутренней бюрократии/внешних разрешений...
Вам бы архитектора нормального. Я бы сделал это с трёх нот за три дня. Пруф. Даже с учётом переучивания ребят на более другие технологии вышло бы не более месяца в неспешном режиме. И не пришлось бы потом никого пристреливать.
Несите таблетки, дед опять бредит!
Зачем пиарить свою недоподелку в приличном обществе? Идите на пикабу, или дтф, там аудиторию свою найдешь.
А приличное общество - это там, где проект пилится на разросшемся шаблонизаторе и звездолёте с детскими болезнями, проезжается по сроками, а потом по 3 раза ещё переписывается с нуля? Что-то мне дурно, скорее же таблетки несите.
Опять же, это лучше, чем брать корявое нечто типа мола, тратить годы на допил, что бы хоть как-то можно было работать, и все равно возвращаться к шаблонизаторам и звездолетам, потому что скорость разработки выше на порядки. Так что да, это очень приличное общество программистов с опытом, и всяких денисов поповых тут не любят. Разве что посмеяться.
То есть $mol вы не пробовали, но мнение имеете. Вопросов больше не имею.
Если бы я пробовал каждую сомнительную поделку от людей, которые не умеют во фреймворки, у меня бы не было времени работать :)
Не обязательно пробовать всякое- по запаху становится ясно. Если же тебе надо еще и попробовать, дело твое, у меня другие интересы.
А вот если бы саморазвивались, читали статьи, пробовали разные подходы, объективно их оценивали, и лучшие из них внедряли, то у вас была бы куча свободного времени, которое вы могли бы без сожаления тратить даже на сомнительные, на первый взгляд, вещи.
То, что я не трачу на сомнительные, не на первый взгляд, а именно сомнительные вещи, и есть результат саморазвития, чтения статей, новых подходов, объективной оценки. Все это позволяет видеть, что мол- бесполезный мусор. Как болгенос ос. Как тысячи иного мусора.
Не, если это поделка студента, еще может быть, как какое-то самообразование. Но зачем впихивать продукты своей жизнедеятельности людям?
Пока, было потешно.
Судя по
сменились тимлид и проджект. Бизнес считал, что проект нормально работает
с жёстким дедлайном в три месяца,
Не выстроен рабочий баланс между тимлидами и бизнесом.
Вангую причины:
Бизнес считает, что лучше знает, сколько длится разработка
Бизнес не верит оценкам тимлидов
Тимлиды "плывут по течению", собирают космолеты на принятом в компании стеке с самого начала, а не предлагают реальные mvp с очень быстрой проверкой гипотез
Тимлиды слишком мягкие, чтобы докладывать бизнесу реальное положение дел
Тимлиды боятся говорить "нет"
В компании нет культуры реального планирования (это когда реально все учатся оценивать, а не делают вид. Это больно и страшно вначале)
Да, амбиций команды было больше, чем опыта в подобных проектах. Можно было назвать пост «очередной Титаник, который мы проглядели», но тут хотя бы всё хорошо закончилось. Да, мы сыграли в Брюса Всемогущего и больно стукнулись (выжатая команда, полувыпущенный продукт, вторая переделка с нуля). Но этот опыт дал то ценное, что даёт возможность нормально двигаться дальше и не совершать подобных ошибок.
Если этот "титаник" еще и "очередной", я бы посоветовал вашему менеджменту от бизнеса и теха сесть и честно разобрать подходы к оценке и запуску проектов. Возможно, их будет ждать очень неприятный сюрприз. А именно, что они вместо реальных оценок и попыток вписаться в эти оценки ( с дальнейшими разборками, почему не вышло и как сделать, чтобы вышло) практикуют wishful thinking с последующими "пускай в следующий раз повезет".
Но этого, конечно, не произойдет пока компания будет расти. Вот когда вы попадете в кризис, возможно и мотивации на изменение появится.
Вы знаете, перечитал ваш пост и не нашел там особой драматичности как в первый раз. Ну да, только с опытом приходит понимание того, что с первого раза конфетка не получится. А молодым инженерам зачастую кажется, что они сразу сделают революционную суперсистему с кучей инноваций.
Понимание приходит с возрастом. Поэтому важно иметь в коллективе опытных инженеров, присматривающих за молодежью. За этим балансом необходимо следить, но это уже тема для другого поста.
Любая работа должна оцениваться нормальным специалистом, должны накидываться часы минимум 10% на форс-мажоры. Если много логики, много непонятных ранее моментов, то запасных часов может оказаться как 50%, так и 100. Сроки определяет не бизнес, а исполнитель. Если исполнитель не попадает в сроки, устраивающие бизнес - увеличивайте штат разрабов или двигайте дедлайны вправо, иначе выйдет говно, которое придется переделывать, что будет дороже.
Если что то можно сделать костылем или долго, то делаем долго. Любой костыль рано или поздно становится стоп-фактором, который потребует пристрелить проект. Это закон. Если сейчас костыль родили за 5 часов вместо нормальной реализации за 40ч, то потом выкинете в помойку тысячи часов и начнете закапывать еще тысячи на новую реализацию. Любого сотрудника, который предлагает костылить или который сделал костыль, надо привязывать к лавке и каждый сотрудник компании должен подойти и высечь его розгами. Чтобы навсегда запомнил, насколько говнокод - это больно. У него должен появиться рефлекс: костыль = очень много боли. А тимлида, который пропускает костыли в работу - гнать ссаными тряпками. В любой работе, в любой среде костыли потом несут кровь, боль, хаос.
Часто слышу такую точку зрения, что если бизнес, через разработчиков, не будет применять все возможные способы обойти конкурентов, включая костыли и "говнокод" - он может не успеть занять место, и потом уже никому качественный продукт нужен не будет, потому что костыльный - сделали раньше и успели доделать "по ходу". Не знаю, насколько это разнится с реальностью
Все эти оценки и грейды быстро разбиваются о суровую реальность и отваливаются. По факту все зависит от опыта. Есть опыт - просто работаешь, нет опыта - работаешь долго и проблемно.
Работы всегда много, поэтому какие-бы оценки не были, человек в любом случае двигается вперед. Терять людей не выгодно, поэтому независимо от оценок, грейды и зарплаты растут, иначе человек быстро уйдет к более заинтересованным конкурентам, где ему голову морочить не будут. Итого, по тому что вижу на практике, оценки и грейды не работают, это просто безусловные ачивки, как диплом в туалете.
Первые 2-3 года людей пытались оценивать, потом просто стали двигать по грейдам без условий, из-за бесполезности сего занятия. Осталось только минимальное ревъю/отзывы, для новичков, для отсева совсем тяжелых случаев. В остальном если человек хотя бы средне тянет свою работу - ему уже присмотр не нужен, гениальности и каких-то достижений никто не требует, достаточно просто работу работать.
В реальности все упирается в основном в процессы: независимо от того насколько человек хорош, он мало что может сделать с недостаточно отлаженными процессами, это даже не его уровень, и не его задача. А процессы почти везде налажены недостаточно - хаос есть всегда и везде.
Устраиваются встречи, обо всем договариваются, все решается, а потом... просто тишина на несколько месяцев. Сомнения, метания, какие-то несогласованные изменения. И внезапно наступает сильная активность: срочно в работу, по новому ТЗ, сделать нужно вчера, боссам уже доложили что все готово, у менеджмента попа горит. Знакомо? Первые пару лет люди пытаются бороться с этим, проактивничают, потом оставляют попытки: это бизнес-машина, так она работает, изменить это сложно. Все быстро меняется: то что вчера было нужно срочно, будучи реализованным в спешке и дорогой ценой уже завтра, внезапно становится не важным, и про реализацию забывают еще на пару недель, а потом опять внезапно прибегают с горящей попой. Абсолютно не согласованный тяни-толкай. Ну и как тут оценивать что-то? Процесс в целом неэффективен, от начала и до конца, на всех уровнях, но причина то не в людях, а в руководстве, которое нередко перекладывает вину на людей через такие оценки - забавное явление. На такие обвинения даже ответить нечего, только фейспалм пробить остается, и поискать компанию с более адекватным руководством.
Два раза не получилось, на третий раз сделали нормально. Хорошо бы как-то заранее научиться делать с первого раза хотя бы приемлемо.
Читая статью вспоминаешь пословицу: "Не в свои сани не садись, не за свое дело не берись"
Надо сказать, что вот эти все "должно быть через месяц" для разработчика являются красным флагом - с такой канторы надо бежать, и ладно, если вы просто гребец - можно сделать лицо кирпичом и веслать в обычном темпе, а если тимлид, то лучше сразу уволится :)
Тот самый случай, когда мы за один месяц рожали то, что надо было делать три (не повторяйте, это больно)