Июль 01

Як програмісти справляються з рутиною: тайм-менеджмент, допоміжні сервіси і правильна комунікація

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

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

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

Тарас Чайківський, 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 часов, а остальное время тратить на развитие (читаю или решаю задачки).