
Як аналітику знайти іншого хорошого аналітика
Одного разу, нічого не віщувало біди.
Як раптом, мій начальник спантеличив мене: «А ось нам на суміжний проект потрібен новий аналітик, давай ти будеш співбесідити кандидатів?»
Я, звичайно, погодився.
А потім подумав і зрозумів, що я поняття не маю як співбесідити аналітиків, а головне, як зрозуміти, гарні вони чи ні. Але відступати було вже пізно!
Тут же надіслані мені резюме, крім невідповідних, були практично однакові. Одні й ті ж якості, одні й ті ж навички, одні й ті ж технології. Пошук по інтернету не обнадіяв, знайдені статті по темі були немов написані одним і тим же копірайтером і особливо допомогти не змогли.
Утворилася ціла орда нібито важливих параметрів, які часто суперечили один одному.
Порозкинувши мізками і порадившись з мудрими людьми я приступив до плану співбесіди.
Замість пошуку абстрактних «золотих» якостей і навичок аналітика, які треба б перевіряти на співбесіді я почав відсікати марні.
У підсумку, марним виявилося все пов'язане з технологіями і додатками. Проект на який я шукав людину був про бізнес-додатки для клієнтів, так що перевіряти знання, наприклад, SQL або JSON не було ніякого резону, а навчити малювати картинки в Sparx можна і мавпу за тиждень. Знання ж всяких UML і BPMN було потрібне лише в контексті розуміння процесу роботи, а не «як правильно малювати кружечки і стрілочки».
Здавалося б, про що питати то тоді? Але в підсумку утворився відмінний план, через який пройшли 17 претендентів.
План складався з трьох частин.
- Загальні вступні запитання.
Які вимоги бувають і якими властивостями володіють хороші вимоги.
Вони потрібні щоб зрозуміти, а чи аналітик переді мною?
Як з'ясувалося в процесі, за красивими резюме приховувалися і тестувальники і розробники і навіть люди, які не мають відношення до IT.
До того ж, ці прості питання дали ще один несподіваний ефект. Деякі претенденти починали психовати, коли їм, власникам таких шикарних резюме, ставлять такі прості запитання. Ну, з такими розмова коротка, психованим в аналітиках не місце.
- Питання про процес розробки і роль аналітика в команді.
Що повинен робити аналітик, а що не повинен. Які у нього відносини з девелоперами і QA, як він розуміє методології розробки в яких учасник і т. д. Практика показала, що далеко не всі уявляють собі весь цикл розробки програми, свою роль у команді і навіщо взагалі бізнес замовляє софт у розробників.
- Ситуаційні питання.
Тут ми моделювали як реальні ситуації в роботі аналітика, так і вигадані мною, щоб простежити за ходом думки претендента. Розглядали звичайні проблеми аналітика: конфлікт пріоритетів або вимог між кількома замовниками, конфлікт всередині команди, нечітке підпорядкування, інтерв'ювання замовника, конфлікт бізнес-інтересів тощо.
Найкорисніший блок, оскільки перевіряв не тільки уважність і кмітливість, а й здатність уточнювати невідомі дані. У деяких ситуаціях я спеціально замовчував деякі ввідні, проте тільки три (!) із сімнадцяти кандидатів хоч щось уточнювали в мене. Що, на мою думку, сумно.
Повністю абстрагувавшись від технічних навичок, вийшов відмінний фільтр для претендентів, всі кандидати, що пройшли його, були схвалені керівництвом і викликали позитивну оцінку на наступних раундах.
Тож якщо ви з такого боку ще не дивилися на найм аналітиків, подивіться!
UPD: Наводжу приклади запитань і очікуваних відповідей.
З вступних питань:
- Який, на вашу думку, головний інструмент аналітика?
Найперше питання. Я свято впевнений що це голова. Але як виявилося, деякі претенденти плутають поняття «інструмент», «навичка» і «компетенція»
- Які вимоги бувають?
Тут достатньо відповіді що функціональні і нефункціональні. Що, нефункціональні можна розділити на бізнес-правила, обмеження та атрибути якості. Що вимоги до відмовостійкості - це атрибут якості, а вимоги до інтеграції - це обмеження.
- Які властивості мають добрі вимоги?
Тут очікував почути що-небудь з цього списку: повні, однозначні, непротиворечиві, перевіряються і розуміються. Можна ще, звичайно, називати, але мені підійде і так.
З питань про роль аналітика в команді:
- Хто оцінює трудомісткість завдань?
Команда розробки
- Хто пише тест план і тест кейси?
QA. Незважаючи на простоту відповіді, деякі претенденти здивували мене тут, сказавши що все це робить аналітик. Для таких у мене було заготовлене питання: «Так що, за вашим QA - це така бездумна мавпа яка тільки і може що кнопки жати за готовими сценаріями?» Але не дивлячись на підказку, пара людей все одно гордо відповіла «Так!» на це питання.
- Хто показує демо клієнтові (у випадку scrum команди)?
Хто завгодно з команди розробки, але не аналітик.
Розіграні ситуації.
- Конфлікт розробника і QA
Ввідна: Приходять до аналітика розробник і QA і скаржаться один на одного. QA говорить що розробник неправильно зробив, а розробник говорить що це QA нічого не розуміє.
Очікувані дії: Треба з'ясувати хто як зрозумів, у чому проблема і в разі косяка з боку аналітика уточнити вимогу, якщо вона трактується неоднозначно.
- Конфлікт пріоритетів
Ввідна: Реліз жорстко запланований за датою, розробки залишилося місяць, все начебто добре, але тут вдається замовник з новою пачкою вимог і говорить терміново додати їх в реліз. При цьому очевидно, що і нові і старі вимоги за місяць не зробити.
Очікувані дії: З'ясувати що спричинило виникнення нових вимог, проговорити потреби клієнта, раптом старі вже не актуальні, тоді їх можна викинути. У разі якщо все потрібно, змусити клієнта самому заново виставити пріоритет і новим і старим і ті що не влазять відкласти на наступний реліз.
- «Забійна» вимога
Ввідна: На етапі оцінки витрат розробник говорить що ця вимога зруйнує систему і щоб її реалізувати треба пару місяців вбити тільки на зміну архітектури. А замовник каже: «Я, звичайно, все розумію, але мені це потрібно, по цьому зробіть, ви ж розробники!»
Очікувані дії: Часто те що хоче замовник - це лише його особисте бачення ситуації і рішення. За будь-якою вимогою лежить якась бізнес-потреба, завдання її виявити і запропонувати більш оптимальне рішення, більш дешеве в плані розробки.
- Інтерв'ю в сліпу
Ввідна: Аналітика відправляють опитати нового замовника, однак про нього нічого не відомо, навіть не ясно ще, що за додаток йому потрібно.
Які головні питання поставить аналітик замовнику.
Наступні питання та їх варіації я вважаю правильними в такій ситуації:
Чим займається замовник і його співробітники?
Навіщо їм знадобилося ПЗ? У чому взагалі проблема?
Що він очікує від цього ПЗ? Який результат?
Як замовник зрозуміє що результат досягнутий?
Які обмеження є у замовника?
- Два директори
Ввідна: Команда аналітика робить ПЗ для міжнародної корпорації з офісами в Лондоні і Нью-Йорку. ПО буде використовуватися клієнтами цієї корпорації. Директори цих офісів є кінцевими замовниками і для успішного релізу вони обидва повинні підписатися. Однак, на одній з екранних форм один директор хоче щоб була синя кнопка і робила одне, а інший хоче щоб була зелена кнопка і робила зовсім інше. Потрібно знайти аргументи, щоб обидва директори погодилися на якесь одне рішення.
Очікувані дії: Через ланцюжок міркувань прийти до висновку що раз директора керують бізнесом, то і аргументи повинні бути пов'язані з бізнесом компаній, а не «давайте зробимо дві різні сторінки» або «будемо визначати клієнта за географічним положенням». Ідеальний варіант - співвідношення вигоди, яку отримає компанія від різних функціоналів з витратами на розробку та обслуговування цих функціоналів.