Закон Брукса (чому ви вирішили, що я про нього ніколи не чула?) — про додавання додаткового програміста на проект. Тут на проекті було 0 програмістів, тому, очевидно, когось додати треба було.
То чувачку просто не вигідно будо послати в дупу і підти самостійно. На нього наїхали в перші же дні, там демотивація і знайшлась інша робота і по був зайчіком (що негласно — не красиво). З іншого боку як думає сучасний греьець із цією фін біщнес моделдю.
контроль за сеньйором має бути майже мінімальний
Зараз не 2010. Інфляція є і у тайтлів. Те що тоді по зрілості людини було сіньор, це тепер staff, principal, senior staff.
Це вже навіть на наших галерах так)
Там ви багато слів написали, що замінюється одною фразою — Закон Брукса. Можна спитати в AI — що воно. Та що колеги вже відмітили, тут головне це : «Клієнт погодив нову функціональність на позавчора, та усі наші інженери були зайняті».
Це й є справжній процес розробки у нашому АйТі?
Це процес у будь якому цивілізованому ІТ, а не тільки «нашому».
Будь яка зміна має «ціну доставки», і та ціна фіксована.
Сініором-новачком. Їм ще ніхто не гарантував, що він реально сініор, яка у нього дисципліна, ставлення до роботи і т.д. Це ж не сініор, який в них вже рік працює.
Як вберегтися від подібного?
Ніякої магії, налаштувати процеси в компанії незалежно від існування ШІ на білому світі.
«ми терміново шукали розробника під проєкт.
На той момент вона шукала роботу вже три місяці й досі була в пошуках. Це насторожило, але, чесно кажучи, часу на довгі роздуми не було.
Що в цьому дивного в наші часи? це дуже середній показник.
Ми не розірвали відносини одразу — і це наша помилка.
На жаль, бізнес- процеси в компаніях такі. Я сама,як кандидатка, проходжу 4-5 етапів + купа тестів. Можливо, в маленьких компаніях 1-2 співбесіди і все. Але, чим більш компанія, тим все складніше.
Коментарі