Тайм-трекінг, код рев'ю та баг-фіксинг. Що для програмістів є рутиною та як справляються з нею

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

Ілюстрація Каталіни Маєвської

Використовує техніки з тайм-менеджменту та пише скрипти

Тарас Чайківський , R&D-інженер в ELEKS

Як на мене, найкраще пояснення, чому виникає рутина, є в книзі Мігай Чиксентмігаї «Потік» (Flow). Основна ідея в тому, що є три стани: тривожність, потік і рутина. Коли вчимося чогось нового, ми стривожені, тому що використовуємо щось уперше. Далі переходимо в стан потоку, все йде як по маслу, і нам це подобається. Відтак одноманітність починає набридати, це — рутина.

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

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

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

Якщо говорити про технічні рішення, то мені допомагає ОС Linux і Python для скриптів. У Linux дуже зручно встановлювати програми з відкритого коду чи пакетів і писати прості програми в консолі (змінити кодування для файлів, розділити дані тощо). Python — тому що ним можна швидко написати щось просте: відфільтрувати розмиті зображення, написати програмку для специфічної розмітки даних і так далі.

Зберігає приклади вирішення завдань

Антон Кузьменко, інженер-програміст з автоматизації бухгалтерського обліку

Рутиною у своїй роботі вважаю:

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

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

Замовник інколи пропонує рішення, які не розв'язків язують його проблеми. І потім усе доводиться переробляти. Щоб постійно не дороблювати одне й ті саме, я уважно вивчаю ТЗ, ретельно обмірковую ситуацію та намагаюсь запропонувати таке рішення, яке справді спрацює. Для цього потрібно зрозуміти, чого реально потребує бізнес, і мати достатню експертизу, у чому прагну розвиватись.

Щоб зменшити вплив рутини на моє життя, я:

підвищую кваліфікацію: читаю технічну документацію, пробую різні варіанти вирішення завдань (тестових і реальних). Розробляю щось для своїх потреб (наприклад, планувальник завдань і базу для зберігання шаблонів);
шукаю цікаві логічні завдання, ігри — складні, з якими треба повозитися. Якщо щось легко дається, це вже не цікаво.
вивчаю нову мову програмування — зараз працюю з T-SQL та Alayska X-Base (щось на зразок Бейсика), вивчаю JavaScript.

Для автоматизації намагаюсь десь зберігати приклади вирішення стандартних завдань. Варто раз розібратися, а потім усе просто: Ctrl+C, Ctrl+V. Немає сенсу щоразу вигадувати велосипед. Конкретний приклад: потрібно дати змогу користувачеві зверни документ зі списком, для цього існує певний перелік дій. Я беру код із файлу та адаптую його для потокового проєкту. Це набагато простіше та швидше, ніж знову писати тієї самий код. До того ж це зменшує ризик виникнення помилок, бо шаблонний код точно працює без помилок.

Старається зробити завдання на швидкість, як бліц

Ярослав Характерник , Golang Developer в Evrius

Рутина, на мій погляд, — це робота, яку хочеться віддати іншому спеціалісту або комп'ютерній комп'ютера. Поділюся прикладами рутинних завдань, які були в мене на минулому місці праці, в інтернет-магазині LeBoutique, ще 2015 року.

Я мав регулярні завдання із завантаження CSV-файлів з інформацією про бонуси в інтернет-магазині. Виправляв помилки та розбивав на менші файли, коли ті приходили занадто великими. Це займало кілька годин на тиждень. Потім ми перевели систему з Bitrix на Symfony і нарахування бонусів автоматизували.

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

Намагається відразу побудувати правильну комунікацію

Сергій Холін , CTO Onix-Systems.com

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

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

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

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

Іноді рутинні завдання, які не вимагають напруженої роботи мозку, даються як невеликий відпочинок:

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

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

Використовує допоміжні сервіси

Володимир Войтишин , Software Architect в ELEKS

Серед моїх завдань рутинними є:
— підготовка естімейтів. Це особливо складно та відповідально для так званих fixed-bid проєктів.
— написання технічної документації. Зазвичай це комерційні пропозиції, архітектурні документи, звіти з архітектурних аудитів. Ключовими аспектами таких документів є не лише технічна достовірність, а й логічна структурованість і зрозумілість.

Робота над цим займає близько 60% часу. Мені подобається виконувати завдання, які умовно можна вважати рутиною архітектора. Вони дають змогу найкраще відточувати навички та бути в професійному тонусі. Яскравим прикладом є побудова архітектури нової системи для комерційної пропозиції. Часто такі рішення є досить схожими: вебпрограма, мікросервіси, база даних, розгортання в хмарі. Основне завдання — виявити ключові особливості такої системи. Як правило, це ті, що забезпечує основну вигоду для клієнта або вирішує найбільш проблемні питання. Далі розповідаємо йому про обраний підхід, розставляючи акценті таким чином, щоб клієнту було очевидно: запропоноване технічне рішення вирішує його потребу.

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

Було б добре мати змогу автоматично візуалізувати архітектуру системи. Особливо це стосується завдань, пов'язаних з аудитом проєктів. Хотілося б також більше автоматизувати розрахунки естімейтів. Наприклад, мати змогу порівняти естімейти для схожих проєктів. Це б суттєво скоротило час, що йде на підготовку комерційних пропозицій.

Щоб швидко оцінити стан програмного коду та виявити потенційні слабкі місця, нерідко використовую статичні аналізатори кодом (наприклад, Sonarqube ). Гарною допомогою у роботі з англійськими текстами є Grammarly.

Намагається згрупувати рутинні завдання і робити їх «пачкою»

Владислав Фурдак , Senior .NET Developer в DataArt

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

Буває так, що рішення задачі займає близько 5 хвилин, а створення гілки, мерджи, очікування статусу білду, затвердження пул-реквестов від колег займає більше часу. Регулярні созвони — від півгодини і навіть до 2-3 годин в день. Якщо проект не тривіальний, складно прийняти правильне технічне рішення або рішення по дизайну системи потрібно обговорювати, слід обумовлювати і вимоги. На рев'ю коду можна витратити до півгодини.

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

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

Як я справляюся з рутиною:

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

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

Мітинги — часто записую технічні зустрічі через скайп, щоб по многу раз не уточнювати деталі.

Рев'ю коду — займаюся, коли хочеться звільнити думки від того, що роблю. Виходить користь і мені, і іншим.

Змінив розпорядок дня і звички

Дмитро, Android-розробник

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

Коли функціонал був дописаний, вся моя робота звелася до того, що я брав додаток, писав ТЗ для дизайнера, потім збирав додаток, тестував і публікував. Це стало для мене рутиною, і під час карантину я зловив себе на думці, що перебуваю у фільмі «День бабака». Кожен день ти робиш одне й те ж. Збірка — це самий великий шматок часу. Займає близько 2 годин. Треба відкривати багато файлів, програм, браузерів і постійно між ними перемикатися і не заплутатися у всьому цьому достатку завдань. З часом я вже не хотів бачити ноут, за яким працював по 8-10 годин.

Щоб впоратися з рутиною і не втратити роботу, я зробив наступне:

Почав читати книги по саморозвитку.
Почала правильно харчуватися, більше готувати і гуглити рецепти.
Пройшов курс з розвитку емоційного інтелекту, дізнався багато нового про себе.
Почав працювати тільки стоячи. У квартирі, в яку я переїхав в Києві, не було столу і стільця, тому працював на кухні на барній стійці. Це виявилося зручно.
Переглянув свій графік: 8:00-12:00 — робота; 12:00-15:00 — спорт, англійська/гітара, обід; 15:00-19:00 — робота; з 19:00 і до сну — перегляд фільмів/прогулянки/турніки.

Зараз компанія вийшла з карантину, і ми повернулися в офіс. Працювати сидячи важко, намагаюся займатися проектами по 5-6 годин, а решту часу витрачати на розвиток (читаю або вирішую задачки).

Опубліковано: 01/07/20 @ 07:00
Розділ Різне

SEO Блог