Справа з оцінками як молодшого програміста

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

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

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

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

• Багато розробників з невеликим досвідом управління оцінюють завдання, використовуючи власну швидкість або швидкість «найкращого» розробника в команді.

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

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

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

З мого досвіду:

• Я думаю, що старший розробник або менеджер повинен мати можливість оцінити історію користувача (бізнес-вимогу) за розмірами футболок (XL, L, M, S, XS).

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

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

• Хороший керівник проекту або старший розробник постійно збирає цю статистику. Коли ваша продуктивність поліпшиться, вони це усвідомлять, і вони направлять більше роботи на ваш шлях.

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

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

Це, на мій погляд, причина того, що оцінки повинні робити люди, яким доручено це завдання (за участю / співпраці від ведучих / однолітків). Ви отримуєте більш точні оцінки того, як довго робота насправді потребуватиме людей.

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

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

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

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

Це звичайне явище.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дозвольте познайомити вас з двома моїми друзями, WAG та SWAG

Тобто, "дикий ослів здогад" і "науковий дикий осел здогадка"

Вірите чи ні, я цього не придумував. Вони насправді досить поширені в бізнесі. Погляньте на цю статтю, щоб побачити, що я маю на увазі.

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

Ключовим є те, що бізнес - це не комп'ютерне програмування. Управління очікуванням важливіше, ніж точність. Важливо оцінити час, який, на вашу думку, потребуватиме плюс 10% як надзвичайний випадок, щоб компенсувати будь-які непередбачувані проблеми.

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

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

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

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

Це важке місце. Здається, що ви застрягли на етапі "просто треба доставити".

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

• Хто зробив дизайн?
• Хто зробив оцінку?
• Хто займається реалізацією?

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