Загалом для багатьох у цьому дописі не буде нічого нового.
Але іноді прості речі виявляються настільки простими й очевидними, що в гонитві за розв'язанням завдання ми їх не помічаємо.
Тому трохи капітана Очевидності для тих, хто думає, як будувати структуру ІТ-розробки.
Отже, як має бути?
У компаніях поза ІТ-галуззю роботу, пов’язану з розробкою програмного забезпечення, зазвичай виконують три групи фахівців:
- Програмісти
- Фахівці підтримки
- Аналітики.
Для невеликих компаній цілком звичайна ситуація, коли один працівник виконує всі ці функції.
І ще кілька не пов'язаних з ІТ. Це норма не лише для ІТ: у невеликій компанії один бухгалтер і зарплату рахує, і платежами займається, і звітність подає...
Зі зростанням компанії працівники дедалі більше спеціалізуються на окремих завданнях.
Так, певний час триває екстенсивний розвиток: ще один бухгалтер на все, ще один програміст на допомогу наявному. Але це неефективно. Натовпом універсальних бухгалтерів чи ІТ-фахівців складно керувати. Таких працівників важче знаходити. Універсали загалом гірше володіють кожною окремою функцією, бо просто не мають можливості заглибитися в щось одне.
Тому зрештою функції розділяють: з'являється бухгалтер з основних засобів, із взаєморозрахунків.
Так само й в ІТ-розробці з'являються:
- програмісти — люди, які пишуть код. Вони зазвичай більше спеціалізуються саме на програмуванні: нововведеннях у розробці, розв'язанні дедалі складніших завдань. І розвиваються в цьому напрямі.
- фахівці підтримки — поки програмісти розв'язують складні завдання, ці люди намагаються якнайшвидше вирішити типові проблеми користувачів: забув пароль, не проводиться документ, немає доступу до товару. Вони мають менше знань із програмування; ключові навички для них — комунікація, стресостійкість, знання можливостей системи. Коли знань бракує, передають проблему програмістам, якщо зрозуміло, що робити, або аналітикам.
- аналітики пишуть ТЗ. Ні, це не означає, що через якусь вавилонську вежу замовники — інші працівники компанії — і програмісти раптом перестали розуміти одне одного. Просто написання ТЗ — інший процес, у якому важливіше розуміти процеси компанії, ніж техніки програмування, мати навички спілкування, ніж пам'ятати всі типи з'єднань у запитах. Найчастіше аналітик — людина, яка зустрінеться із замовником стільки разів, скільки потрібно, налагодить процес: визначить, як відбуватиметься робота після автоматизації ділянки, формалізує домовленості й узгодить їх з усіма. Потім передасть ТЗ програмістові. Після завершення автоматизації супроводжуватиме впровадження й передасть потрібну інформацію службі підтримки.
У розробці є й інші ролі та спеціальності, але для спрощення я назвав основні. Пам'ятаємо: йдеться про внутрішню розробку сервісного ІТ-підрозділу в компанії поза ІТ-галуззю.
Важливий момент: усьому цьому оркестру працівників різних спеціальностей потрібен диригент. Головний бухгалтер або фінансовий директор для бухгалтерів, ІТ-директор — для ІТ-фахівців.
Якщо для кожної функції немає окремої посади, чи означає це, що з компанією щось не так? Ні.
Просто це такий етап. Погано, коли рівень компанії — кількість працівників, складність процесів, масштаб автоматизації — не відповідає рівню розвитку структури ІТ. Тут уже море ризиків і безліч випадків неоптимального використання ресурсів.
Про розподіл функцій потрібно знати.
І в певний момент під тиском нерозв'язаних завдань не піддатися бажанню найняти ще одного, шостого програміста, а замислитися над створенням служби підтримки й відділу аналітиків, які розвантажать розробників і підвищать їхню ефективність.