Уміння спілкуватися є набагато важливішим за технічні знання

12 серпня
Кріс Шелдон, Senior Project Manager у DataArt
Уміння спілкуватися є набагато важливішим за технічні знання
Що відбувається, якщо поквапитися заглибитись у деталі та на дуже тривалий час зосередитися на написанні коду? Чому прагнення до технічної досконалості не завжди радує замовника? 12 років тому Кріс Шелдон, менеджер проектів DataArt із Лондона, був розробником-початківцем, впевненим, що навички програмування — це все, що йому знадобиться у професії.

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

Навіщо дорослі вчаться розмовляти

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

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

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

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

Робити свою справу незалежно від обставин

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

Йшлося про ATS-системи управління кандидатами, які дозволяли частково автоматизувати процес найму випускників.

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

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

Минуло шість місяців, я освоїв усі існуючі в компанії системи і став у сто разів більше розуміти у програмуванні. У нас з'явився баг-трекер, а розбиратися з багами якраз доручили мені, і я намагався робити це максимально швидко. Робочий процес було налагоджено: список помилок був доступний онлайн, і клаптики паперу з вимогами зникли без сліду. Кожен усунений баг забезпечував мені невелику дозу дофаміну, тож робота мені подобалась.

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

Кожну клієнтську систему ми розробляли індивідуально за єдиною методологією:

  • Копіювали існуючу систему.
  • Вносили в копію зміни, поки всі вимоги не будуть враховані.

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

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

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

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

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

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

Відгук клієнта був, м'яко кажучи, емоційним: «І де в цій формі поле для номера дозволу на роботу? Як людям подавати документи?!». Чи треба уточнювати, що я про таке поле чув вперше? Проект потребував безлічі змін, і рівень кастомізації системи в підсумку виявився куди більш значним, ніж я міг припускати.

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

Agile: більше ніяких аркушів

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

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

Але до того роботодавець встиг зробити мені справжній подарунок у вигляді проекту нової системи сучасною за тодішніми мірками мовою програмування. Ми переходили з Classic ASP на ASP.NET WebForms — копіювати цілі системи тепер було не потрібно. Проект передбачав співпрацю за принципом White Label і фактично відкривав нову технічну еру для компанії.

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

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

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

  • Взаємодія з клієнтом.
  • Реакція на зміну вимог.

Загроза ізоляції

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

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    31 грудня