Запостив я отакий шорт на ютубі в підтримку останнього відео і отримав у коментарях наступний діалог:Коментатор: а в кінці місяця, без тікетів , вирішити хто працював ,а хто штани протирав?Я: Бгггг. Чи це серйозне питання було?)Коментатор: так серйозне,валідую інформацію. а чому це так вас дзивувало? я не айтівець, але бачив відео що стікери портібні. читав жарти що сеньйор без стікера не працбє)Ну я й зрозумів, що тут дійсно варто відповісти прямо розгорнуто (це найдовший мій коментар на ютубі в принципі), для чого тікети в джирі насправді, яка вони мають працювати, і кого мав на увазі Артем у цьому фрагменті. Тому наводжу свою відповідь як є, а ви вже вирішуйте самі, чи достатньо розгорнуто я відповів:***Тут як. Колись дійсно тікети в джирі багато хто використовував для обліку робочого часу. Я сам таку практику застав. Відверто — це херня. Бо це нічого не дає, крім можливості підкручувати собі години.Щодо того, що синйьор без тікета не працює. Тут скажу, що й мідл і джун теж не мають. Але з іншої причини. Задачу в тій же джирі варто сприймати як точку опори. В ній має бути описано що робити, в яких межах, які залежності у задачі, хто причетний, додані потрібні посилання. Якщо стиснути до одного визначення, то тікет, або, як ти кажеш, стікер — це по факту документація до задачі.Це дозволяє уникати непорозумінь "а чому це і це не зроблено? а чому це і це зроблено так?". Бо в такому випадку є джерело правди, з яким мають бути ознайомлені усі учасники робочого процесу. Тобто коли умовний менеджер починає шось там вимахуватись, перед ним ставиться аргументу — "ти бачив документ до початку роботи". Така собі страховка.Тобто очевидно, що робота без тікета — це абсолютно невизначена величина, яка призводить до ще більшої невизначености, бо кожен може тлумачити задачу по своєму.Але в даному фрагменті мається дещо інше на увазі. Тут Артем казав про ситуацію, коли ми маємо безініціативного виконавця, який ніби й буде робити задачу, але тільки тоді, коли ХТОСЬ інший ЙОМУ зробить тікет. Вирішить за нього усі питання, уточнить незрозумілості, і на тарілочці подасть фінальний документ. І аж тоді наш програміст підніме дупцю і піде шось там кодірувать.Колись такий підхід працював. Зараз — не дуже. Чому? Бо нам потрібна відчутно менша за розміром команда ініціативних людей, які можуть самостійно розібратися в домені, контексті задачі, які можуть самотужки налагодити потрібну комунікацію, які можуть керувати невизначеністю. На противагу команді видатних кодогенераторів, які пальцем не ворухнуть, поки їх не натицяють носом в усе готове.Є хороша приказка — "зроблене краще за ідеальне". Вона пасує і сюди. Поки хтось буде чекати, поки за нього все порішають, інший почне розбиратися сам, робити якісь початкові версії і ітеративно покращувати рішення. Можливо, такий код буде гіршим. Але його перевага в тому, що він все-таки буде.А ініціативний виконавець при цьому ще й розумітиметься на контексті всього продукту, і зможе пропонувати усе кращі й кращі рішення. Навіть такі, як не робити нічого. Бо це може бути кращим для продукту. Тому для бізнесу такі проблем солвери й набагато цінніші за просто чудових програмістів.Якось так.***Ви вже подивилися це відео? Це просто відвал сраки, наскільки воно вийшли цікаве та круте.https://www.youtube.com/watch?v=oyswnHaq_3E