Давайте порахуємо, скільки дійсно робочих годин є у 40 годинах

У JetSoftPro, як і у більшості IT-компаній робочий тиждень девелопера вміщає 40 робочих годин. 6 років тому компанія Scoro (трекінг робочого часу) проводила дослідження і встановила, що працівники витрачають до 40% робочого часу на речі, не пов’язані з роботою. Це підтверджує численні дослідження продуктивності, які говорять, що дійсно продуктивними можна вважати 5, 4 і навіть 3,5 години на день.

Давайте розбиратись, куди витрачається неробочий робочий час, і за що компанії платять девелоперам.

Час тече по-різному

Не занурюючись у глибоку фізику, згадаємо, що для різних людей час тече по-різному. Скажімо, 1 рік для 7-річної дитини — це дуже довго, адже це 1/7 її життя. А для 35-річного батька 1 рік відбувається швидше, адже це 1/35 його існування. З віком час пришвидшується.

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

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

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

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

Відпочивати швидко або повільно?

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

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

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

А як же тоді рахувати час на виконання задач?

Диявол заходить в переговорку, сідає навпроти боса і говорить:

  • А чого ти їм платиш за 40 годин, якщо вони працюють 23?

Бос не відповідає, бо вже другу годину п’є каву з рекрутерами у них в кабінеті, де його ніхто не знайде.

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

Найбільш прийнятний спосіб, як я це бачу, — це естімейт всієї команди по рівню стронг джуна. Скільки треба часу стронг джуну на задачі, стільки і вся команда витратить. Правило просте: упряжка їде зі швидкістю найповільнішого коня.

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

Чи можна скоротити час на відпочинок?

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

Є і більш адекватна альтернатива. Можна просто дозволяти девелоперам відпочивати так, як їм зручно, але привчити їх вкладатись у часові межі проекту. J

PS

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

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

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

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

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

Може треба вже визнати, що з роботою мозку всі оці «трекінгі часу» тупо не працюють? Людина або робить свою роботу якісно, або ні.

Шановні, ну камон.
Ну перестаньте вже гратися, і вдавати що software development це як фабрика, тільки з наворотами.
Рахувати робочі години, оцінювати продуктивність за зміну, контролювати відвідуваність.
І саме популярне — робити естімейти так наче ми тут всі грузим вагони (тіко віртуальні), а не девелопим софт.

Так що камон — 50+ років індустрії, а ви не вигадали нічого краще ніж слизати робочі процеси в індустріальних фабрик минулого століття.

Омг, знову рахують години. А стрічки коду теж рахуєте?
Тікайте з таких контор де менеджери не про продукт думають, а про години, естімейшни, кпі, і інший булшіт.

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

Я вийшла працювати почасово, а завжди була на фултаймі. І в перший місяць у мене було багато питань, який час мені біллити клієнту, а який ні. От наприклад (утровано) якщо я каву пішла попити на кухню на 10хв — це робочий час, чи ні? А якщо на 20? Здається, що то неробочий час. А якщо каву пила та про таску думала?

Прочитала на форумі фрілансерів, що перерви до 15 хвилин білляться, тому що ти не випадаєш з контексту і тому що це «виробнича необхідність». Остаточно переконалася, що неможливо «справедливо» вичислити час роботи, коли мені пів-ночі код снився, і наранок в голові було готове рішення. Тож, мій мозок думає навіть вночі — це біллити чи ні?

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чим більше досвіду тим більше часу займає обдумування. Більше.
Більше.
Це як виконувати запит до майже переповненої бази даних. Так, всі ті where — тобто умови за яких рішення буде найефектівнішим та найоптімізованим вони у досвідченого у більшій кількості знаходяться. Тому запит більш складний.
Чим складніший запит тим більше більше часу на обробку. Досвід уповільнює розробку хоча і робить результат кращим ніж у джуніора.
А ось напрацьований автоматизм друкування та знання хот кейс та ключів (тобто послідовностей сбірки) навпаки збільшує швидкість розробки у порівняні із тик-мик джуніора
Тобто — це все трохи сбалансовано ось так:

Джун                                         Сеньор
30 - 70                                        70 - 30
100 поганенького коду            100 гарненького чепурненького коду

Якщо за п ять років наш сеньйор не створив хоча б маленької власної фірми — він мабуть теж джун. На галерах приковують... Але кого?
P.S.
Який же він сеньйор, якщо власний досвід та знання не забілдить у якусь експертну систему, яка буде пам ятати за нього все що йому треба.
Хоча б власний набір *nix скриптів...

Деякі сильні інтелектуали можуть працювати без відпочинку 16-18-20 годин, але — важливо! — після цього їм треба спати здоровим сном не менше 12-14 годин.
Це не вкладається у стандартний робочий графік. Саме тому такі люди — виснажуються більше і серед них більше тих кто звільнується (вигорання, втома)
Що до їх роботи вона бездоганна звісно — допоки не втомляться...
P.S.
Це все збудження нейронів. Чим довше мозг працює без відпочинку тим збудження нарастає і врешті решт починає заважати нормально працювати.
Щоб зняти збудження — треба спати тим довше чим воно більше.

Олеже, чому? В деяких компаніях якщо уданому релізу передовало 16-18-20 годин праці, то наступного дня працівникам дають виспатись, всі це розуміють.

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

Згоден, щоб рахували 4 робочі години на день (20 годин на тиждень), якщо:

  • погодинна оплата роботи стане х2
  • кількість мітингів зменшиться у 2 рази

Повітряні тривоги врахували?

Час, необхідний на відновлення, збільшується і з робочим досвідом. Згадайте свій рівень «егегей» у перші дні на роботі, і тепер.

Неправда, все залежить від того, цікавий у тебе проект (чи задача) чи ні. Якщо цікаво — то «егегей» навіть якщо в тебе багато років досвіду.

Это если у тебя опыта до пяти лет, после этого любая работа это просто работа

Я вийшла працювати почасово, а завжди була на фултаймі. І в перший місяць у мене було багато питань, який час мені біллити клієнту, а який ні. От наприклад (утровано) якщо я каву пішла попити на кухню на 10хв — це робочий час, чи ні? А якщо на 20? Здається, що то неробочий час. А якщо каву пила та про таску думала?

Прочитала на форумі фрілансерів, що перерви до 15 хвилин білляться, тому що ти не випадаєш з контексту і тому що це «виробнича необхідність». Остаточно переконалася, що неможливо «справедливо» вичислити час роботи, коли мені пів-ночі код снився, і наранок в голові було готове рішення. Тож, мій мозок думає навіть вночі — це біллити чи ні?

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

Скільки працював — стільки і є :)

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

Яка різниця скільки продуктивних годин, якщо зарплатня — одна й та ж сама.
Точніше як. При одній тій самій зарплатні та задоволеному менеджері чим менше робочих годин в 40, тим краще :-)

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

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

Ну сейчас трекеры умные — на раз найдут такое, так что нужна норм симуляция.

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

Це управління часом. Хто контролює час той контролює все.

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

Мы исключали все время, проведенное в Steam и других не совсем релевантных окнах(например Telegram, который мы не используем в работе). Мы трекали только время, которое программист активно тычет кнопки и таскает мышку + коллы. За несколько месяцев статистики мы поняли, что активной работы за компьютером у программиста выходит около 3,5 часов в день. Бывают пики по 5-6 часов раз неделю и совсем экстремальные случаи по 7-8 часов активной работы, после которых следовало несколько дней совсем вялой работы, не помогали даже выходные.

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

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

За несколько месяцев статистики мы поняли, что активной работы за компьютером у программиста выходит около 3,5 часов в день. Бывают пики по 5-6 часов раз неделю и совсем экстремальные случаи по 7-8 часов активной работы

1) якісь хілєнькі у вас девелопери, або проект нецікавий
2) коли людина, яка могла б працювати 6 годин, бачить що всі працюють 3.5 і їм це прокатує — вона думає «а я що тут, сама дурна?» і починає робити те ж саме — тому це може бути наслідком такого peer effect

або проект нецікавий

=)
Як може бути цікаво батрачити 6+ годин на чужий проект?
Якщо вже людина задрот то можна тих 3.5 годин + навчання.
А працювати щоб працювати, в чому смисл?

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

По вашому цікавість проекту можна оцінити інтенсивністю клацання мишкою чи клавіатурою?

Ні, це так не працює. Навіть вантажник не може вантажити всі 8 годин — він працює годину, годину відпочиває +/-.

Навіть якщо вантажник буде дуууже мотивований працювати без перерви (якщо йому сказати, що все, що відвантажить за зміну — забере додому, наприклад) наступні 2-4 дні він буде тупо лежати.

З мозком майже те саме. Я працюю, наприклад, над своїм, дуже-дуже цікавим мені пет-проектом 8 годин, і наступні 2-3 дні нічого вже не можу. Хоча проект — дуже цікавий та дуже мотивує.

В нас дуже сильні (як до кожноденної активності) м’язи та мозок, але вони такі, не для того, щоб видавати постійно «пікову» потужність, а для того, щоб короткочасно видати ту саму пікову потужність, якщо треба вижити.

Звісно, під социум ми підлаштовуємось, але «вище голови не стрибнеш» (або швидко згориш)

1) Працювати весь час по 6-8 годин нереально. Я вийшла на новий проект, пару тижнів працювала повноцінні 8 годин, бо роботи було багато і треба було багато в чому розібратися, і за ці тижні втомилася так, що тепер мені потрібна відпуска.
2) Це тільки якщо в людини немає синдрому самозванця, бо мені, наприклад, завжди здається, що інші працюють більше та ефективніше за мене, хоча це частіше за все не так.

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

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

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

Було б круто якби хтось придумав, як зробити оплату за результат а не за години, бо виходить хто повільний той і більше заробляє (чим довше робиться таска тим більше грошей)

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

Майте на увазі, що при такому типу співпраці ризики мають обідві сторони. І це не всім підходить.

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

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

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

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

В том-то и проблема, что если сам делаешь задачи на назначаешь на них сроки («обещаешь»), то тут как-то оценить человека можно, а как быть, если сроки назначает не он сам, а так обычно и бывает?

Я правильно понимаю, что свой частный случай Вы транслируете на всех? :)
Правда тот, кто понимает, кто что может и за какое время, это уже тимлид, техлид должен заниматься немного другим... но тут уже кто как называет.

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

Ну бывает же так что задача там на месяц, а сделать надо на вчера (до конца спринта за 2 недели) и конечно ты не успеваешь и конечно потом к тебе вопросы. + Есть такая тема как требования которые меняются в процессе разработки)

Эстимейт своих задач — вполне нормальная обязанность для программиста. Эстимейт и является обещанием сроков.

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

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

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

По факту сіньор оцінить в тиждень і буде робити годину

20-25 годин. Усе інше — анімовані гіфки з кошенятками

Більша частина роботи як завжди в тому, щоб прибрати хаос. Зрозуміти, що власне треба робити який результат потрібен, розповісти про це іншим так щоб вони зрозуміли тощо.
Як завжди, якщо ви такого ще не робили, будете бігати зігзагами. І от коли сили пішли в цю прірву, потім ще треба, блін, по ночах скажімо програмувати, налаштовувати щось чи вчити фреймверк (найпростіша справа насправді, коли тебе на відволікають) .
А хаос це завжди одне і те саме — бігання зигзагами та Терміново-манать-пісець-ААА! З однієї точки зору, трекання кожного робочого часу це такий собі варіант бюрократії і мікроменеджменту. З іншої враховувати час абсолютно точно треба, час це єдиний невідновлюваний ресурс. Саме тому і існує менеджмент, ставлять цілі, дедлайни, планують тощо. Деталі як можна знайти у : Демарко, Демінга, Имаи, Якокі, Адізеса тощо. Є такі знання котрі не старіють.
Точно скажу усім менеджерам і лідам, які нещодавно стали такими — якщо якась задача не йде, треба розібратись чому власне вона не йде і допомогти, швидше за усе з задачею щось не те, або вона не зрозуміла (люди не вміють читати чужі думки), або андерєстімейт, або це якась XY проблема тощо — а не робити мітинги кожен день на пів дня де казати, що ось це завдання дуже потрібне клієнту і бізнесу позавчора.
Якщо вже відбувається мітинг — з нього має бути якийсь вихлоп, скажімо план дій щодо вирішення проблеми. А якщо вимагати детальний звіт на 50 сторінок, що було зроблено кожної години — вийде так, що час пішов якраз на мітинги і створення звітів.

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

насправді — не завжди. Буває, що я працюю і по 10-12 годин на день. Але наступний тиждень — гарно, якщо по 2-3. Краще за все, з мого досвіду і спілкування з колегами — десь 3-6 годин на день, в залежності від складності та стресовості (швидкість, можливість щось зламати, таке) задачі. І найбільша продуктивність на великих термінах (місяць і більше), коли ти працюєш рівномірно кожен день. Тобто — ці самі 3-6 годин (+ пошта, входження у «потік», планування, читання) — загалом десь 8 і вийде. І виходить, що трекати час сенсу то і немає. В тебе є 8 годин, ти працюєш над задачами скільки можеш. Будеш працювати більше — просто вигориш.

Вроде подсчет часов закончился с началом ковида, когда все пошли работать фром хоум.
Я доступен 40 часов в неделю в тимсе, а там уже сами себе рисуйте графики на что я их трачу😀

Відпочинок це теж частина роботи

Завжди знайдеться хтось, хто зробить ту роботу дешевше. Ось якщо не знаходиться...
Втім, профспілки у них немає.. (погуглив «профспілка українських програмістів»)

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

у 40 годинах робочих годин залежно від відстані до дедлайну.
Без дедлайну у 40 годинах десь до 5 робочих годин :))))

Просто оставлю это здесь.

So the call center tried its own experiment. Instead of staggering employees’ coffee breaks as it had previously, it aligned their breaks to allow more chatter. The result, Bank of America told MIT a few months later: productivity gains worth about $15 million a year.

Отсюда.

Це підтверджує численні дослідження продуктивності, які говорять, що дійсно продуктивними можна вважати 5, 4 і навіть 3,5 години на день.

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

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

Омг, знову рахують години. А стрічки коду теж рахуєте?
Тікайте з таких контор де менеджери не про продукт думають, а про години, естімейшни, кпі, і інший булшіт.

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

після цього все навернеться, бо працювати буде нікому)))

не обов’язково. Можна займатись простими задачами, де усе «зрозуміло». Таких задач теж досить. Інколи треба просто «зробити кнопочку на сайті».

І контора буде братися тільки за формошльопство, бо там зрозумілий для менеджмента «прозрачный и понятный таймшит».

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

Звісно, є і просто ледахи. Це ризики. І саме це є завданням — управляння ризиками, а не таймщітами...

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

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

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

Може треба вже визнати, що з роботою мозку всі оці «трекінгі часу» тупо не працюють? Людина або робить свою роботу якісно, або ні.

Если человек не занят написанием документов и не занят написанием кода, значит он занят анализом задач. Результат анализа — сообщение в письменном виде на форумном движке. Весь анализ фиксируется также в Jira, с указанием времени и ссылкой на результат анализа. Оценивают качество и глубину анализа Senior разработчики, если они на проекте есть.

В этом нет никакой необходимости, разработчик получает задачу на 4 часа времени, делает её за два, трекает её в Jira, ещё два часа занимается чем хочет.

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

Що до аналізу задач — я можу пояснювати, наприклад, доньці як рішати домашнє завдання, чи як щось там працює — і саме це «наштовхне» мене на рішення моєї задачі. тож, наштовхнуло — пішли затрекали, не наштовхнуло — не затрекали? Навіть, якщо весь час про це міркував? Чи як? Я офіційно поїхав у відпустку, повернувся і написав код за день — мені трекати день, чи пояснювати менеджеру, що я у відпусці багато чого робив і саме тому тут і зараз зробив це за час? А нову відпустку я можу відразу просити? ;) А як відреагують, якщо я на початку робочого дня затрекаю відразу 4 години — вчора за вечерьою, з ранку, поки збирався, їхав, та поки був перед роботою у залі? ;) А якщо не зробив задачу — не трекати? А нічого, що все одно виснажився, але це як, за свій рахунок?

Нехай буде у нас вантажник, якому приносять коробки різного розміру, і вагони — теж різного розміру. І він не тільки вантажить, але й, інколи, перекладає по кілька разів — поки не знайде оптимальне рішення по загрузці вагону. Рахуємо по часу? Так замовник же скаже — а чого сьогодні 2 вагони, а вчора — 4? По вагонах? а нічого, що вчора склалося з першого разу, а сьогодні 2 раза перезавантажував вагон бо принесли у останню годину нестандартний контейнер і треба було винести все і скласти знову? Чи спочатку було не зрозуміло, чи стане чи ні — бо «лінійки» тут тупо немає? А у працівника, що працює розумом задачі можуть «рішатися» у не робочий час. І що з цим робити? Та в мене навіть робочі ремонт час від часу робили не за квадратні метри, а за годину — бо було не зрозуміло, чи треба тільки замінити штукатурку, чи взагалі перекладати стінку, поки не зняли стару. Та навіть, найпростіше — можна викопати яму у грунті, а можна копати ямму і наштовхнутись на комунікації, бетонні блоки, корені та інше- це як, по кубометрах рахувати? чи вже за часом? А якщо за часом — чого Вася копає куб за годину, а Петро — за дві? А завтра той-же Петро — за півтори? І таке інше.

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

працює в тому випадку коли ти о 6й вечора йдеш з роботи (не важлово зробив не зробив) й до наступного ранку про все це не думаеєш. Допускаю що комусь навіть так зручніше. А так згоден.

Не зовсім. Якщо робота тобі дійсно цікава, то на 100% ти її з голови не викинеш. А якщо не цікава, то ви просто не зможете підтримувати ефективність роботи на достатньому рівні більш-меньш довго.

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

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

Якщо робота тобі дійсно цікава, то на 100% ти її з голови не викинеш.

ІМХО, в таких випадках треба йти до лікаря)

Ми майже третину життя витрачаємо саме на роботу. Третину (!), і майже половину — активного часу (якщо відкинути сон). Робити щось, що не подобається, половину життя, навіть за гроші — це якийсь ... ну не знаю, мазохізм?

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

Тож, це дуже суперечливе питання, кому і коли треба їти до лікаря. ;)

Тобто, «вона працює» для не мотивованих (низькоефективних) робітників

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

Якщо робота тобі дійсно цікава, то на 100% ти її з голови не викинеш.

Можеш описати що таке дійсно цікава робота? Бо щось та айтішна рутина не здається мені сильно цікавою

Тут кожному — своє. Мені, наприклад, подобається кодити. Вирішувати складні задачі. Подобається python і пер-проект на ньому-ж. По роботі пишу модулі на terraform — сама мова так собі, але цікаво коли треба з якоїсь складної структури даних на yaml перетворити у кілька, під створення ресурсів. На python теж пишу — отримання даних з хмари, з сервісів. Подобається розробляти архітектуру классів, архітектуру сервісів (бо частина деплоїться через terraform, частина — через ansible... Тобто, цікавих задач достатньо. Як на мене.

Подобається розробляти архітектуру классів, архітектуру сервісів

Це займає не більше 1% часу. Далі йде мавпячий кодінг

Коли як. Я ж кажу — кожному своє. У мене, наприклад, більшість часу бере саме планування. Коду не так і багато. Я дуже не люблю щось переписувати. ;)

Взагалі, як на мене, ідеальна робота — коли тобі подобається все, що ти робиш. Звісно, на 100% так не буває. Інколи треба і щось нудне робити. Але до цього треба так само йти, як і до нормальної оплати своєї праці. ІМХО.

Згоден із тезою, що мозок — не м’язи, але не згоден із тим, як оцінювати роботу над задачею. Буду суб’єктивним, але і я, і мої колеги, виконуємо схожі задачі. Інакше будь-яке планування було б неможливим: «Скільки треба часу, щоб написати отакий-от парсер?» — «Не знаю, я творча людина, подивимося як піде». Творчі задачі існують, але їх мала кількість; якби ви не знайшли хороше рішення задачі до певного часу, то після певного часу все ж зупинилися б на гіршому. І більш досвідчений працівник (а не більш творчий) приходить до оптимальніших рішень за той самий проміжок часу, що його менш досвідчений колега. Якраз здатність виконувати типову роботу в типовий термін і відрізняє ремесло від творчості. А роботодавці наймають не митців, а ремісників, у першу чергу.

dou.ua/...​rums/topic/39283/#2455378

Для простих та передбачуваних задач — так. Та й навіть тоді я б не оцінював погодинно. Ми, наприклад, не рахуємо години взагалі. На початку тижня розбираємо задачі та обговорюємо приоритети. Приблизно зрозуміло, що хто буде робити і в якому порядку. Можна взяти і одну велику задачу на тиждень, і одну — на день, і кілька на день, але планувати їх ще і погодинно... Ну, таке. Все одно точність ± ті саме 2-3 години на день + сам час на більш точне планування — і ось уже на задачі залишається меньше часу.

>

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

Пане(чи пані?), працювате на вас я, звісно, не буду, але ви можете заплатити мені за відпочинок. Куди надіслати реквезити?

Шановні, ну камон.
Ну перестаньте вже гратися, і вдавати що software development це як фабрика, тільки з наворотами.
Рахувати робочі години, оцінювати продуктивність за зміну, контролювати відвідуваність.
І саме популярне — робити естімейти так наче ми тут всі грузим вагони (тіко віртуальні), а не девелопим софт.

Так що камон — 50+ років індустрії, а ви не вигадали нічого краще ніж слизати робочі процеси в індустріальних фабрик минулого століття.

Так треба цим користатись)
Два коміта в день і ти вільний)

Крупные задачи делятся на небольшие подзадачи. Минимальное время на задачу — 2 часа. Кажется что 2 часа это много, но на самом деле в неделю это 40 часов, а в месяц 160 часов. И заполнить таймшит на 160 часов, чтобы он выглядел адекватно, не такая простая задача. Если человек справился не за 2 часа с задачей, а за полчаса, всё нормально с программистом. Если программист не справился за два часа, словил гонки и возился 4, но указал 2, то с ним тоже всё нормально. Главное, чтобы всё шло по плану.

Тільки процесс розділення задачі на підзадачі — таж задача, яку треба зробити, і зробити якісно. Тут як з архітектурою — помилка може коштувати дуже дорого. Але чомусь це не помічають. Більш того, сама задача розбиття на маленькі задачі може бути велика і не ділитися на маленькі ;) Точніше, скажемо так, «на достатньо маленькі».

Есть тип задачи — проведение анализа, проектирование. Результат анализа — сообщение на форумном движке, открытые задачи в Jira.

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

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

«Трекінг працює» лише для менеджерів, як матеріальне свідоцтво, що вони щось роблять — можна замовнику показати кількість годин та задач у жирі. Бо показати мотивацію персоналу та роботу з ризиками — значно важче (якщо взагалі можливо).

Тому програмісти його і не люблять — бо це не робота програміста, це робота менеджера. Перевірити, хто і що зробив. Але її спихнули на програміста. Бо менеджер не взмозі ніяк оцінити, що саме робив програміст та скількі часу для 99% задач. У мозок не залізеш. Яму чи вантаж можна «пощупати». А як «пощупати» роботу мозку?

Я бачив купу систем — і по кількості задач, і по затреканому часу. Але це працює тільки для простих, однакових, передбачуваних задач. Трошки в сторону — і все це профанація. Менеджер починає писати в планах щось «з голови», програміст починає трекати «від ліхтаря». До реально затрачених зусиль та часу ці числа не мають ніякого відношення, і, навіть, не мають ніякої передбачуваної сили — бо те, що сьогодні Вася зробив за день, завтра Вася зробить за 2 (ну, не виспався, чи купа інших причин), а Павлик — взагалі за 3 дні, чи за час.

А причина — без ТЗ результат ХЗ

Трекінг ще як працює, просто програмісти його дуже не люблять.

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

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

Ноль менеджеров? Это даже не sci-fi, это что-то из фентези...

Есть Team Lead программист, есть бизнес-аналитики. А менеджер самое главное чтобы занимался чем угодно, только не командовал программистами.

Team Lead вирішує технічні, архитектурні питання проекту.

Менеджер повинен вирішувати всі інші, щодо взаємодії людей на проекті. І він не командує. він організує взаємодію (в ідеальному світі принцес та рожевих поні :D)

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

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

У менеджеров и БА обычно просто часов 6 митингов а день) вот уже и протрекали)

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