Погодьтеся, комунікація – необхідність сьогодення. Вміння чітко доносити свою точку зору, слухати і чути іншу людину, вчасно задавати питання, конструктивно критикувати когось і адекватно сприймати критику у свій бік – це все зробить вас бажаним кандидатом на омріяну позицію.
Сьогодні розглянемо тему ефективної комунікації для розробників.
У промисловій розробці програмісти не пишуть код на свій розсуд. Вони втілюють у життя ідеї нових продуктів або автоматизують бізнес-процеси. Відповідно, усвідомлення того, який код необхідно написати, є результатом аналізу вимог, спілкування з замовником, менеджером та тімлідом. Відповідність результату очікуванням замовника та якість написаного коду залежить також і від комунікацій вже в процесі роботи. Від нашого вміння сприймати, надавати та запитувати інформацію. Ці вміння визначають наскільки якісно, швидко, та повною мірою будуть досягнуті цілі розробки продукту. І тут молодому спеціалісту допоможуть декілька простих порад:
- Найдурніше питання – не задане. Інколи, ми вагаємося щось запитати чи звернутися за допомогою через страх видатись дурними або переймаємося, що не можемо коректно ставити запитання. На інтернатуру ви прийшли навчатися. Тож використовуйте цю можливість по максимуму. Адже цього від вас очікують. Тренуйтеся чітко описувати ситуацію та формувати запит на допомогу.
- Правило 15 хвилин. Цінність розробника визначає його здатність самостійно вирішувати задачі. Але й битись з проблемою 1 годину там, де тіммейт може допомогти за 5 хвилин теж фінансово неефективно. Користуйтеся правилом 15 хвилин. Якщо за 15 хвилин не вдалось вирішити проблему самостійно – просіть про допомогу.
- Питайте ментора. “Сусіда по парті” запитати простіше. Він і ближче, і твого ж віку, та й ментора не хочеться відволікати, раптом ще розсердиться. Та у сусіда мета навчитися самому. Це не його відповідальність – навчити вас писати код. Для цього є ментор. Саме він допоможе розібратися, з чим саме та чому у вас виникли складнощі, та дасть базу для їх вирішення у майбутньому. В першу чергу завжди питайте ментора.
- Давайте зворотний зв’язок. Як переконатися наскільки вірно ви зрозуміли поставлену задачу? Можна витратити 2 дні на розробку і показати готовий результат. А потім ще день виправляти неточності та зауваження. А можна переповісти, як ви зрозуміли задачу, яка її мета і що будете робити для її вирішення. Займе це 5-10 хвилин і ви одразу будете розуміти чи все добре, або можливо варто ще попросити про додаткові пояснення. Завжди надавайте зворотній зв’язок. Детальніше по цій темі слухайте в подкасті Podlodka #183 – Обратная связь.
- Більше контексту. Звертаючись із питанням, майте на увазі, співрозмовник може не пам’ятати (якщо взагалі колись знав), над якою задачею ви зараз працюєте. А говорячи про вирішення проблеми, скоріш за все не знає, які кроки ви вже виконували та які результати отримали. Завжди починайте з контексту.
- Керуйтеся вимогами, а не припущеннями. Не варто очікувати, що вам хтось надасть документ, де детально розписані вимоги з усіма подробицями. В Agile культурі розробки вимоги з’являються в процесі спілкування команди із замовником чи власником продукту. Усі нетехнічні нюанси, які неформалізовані в наявних вимогах мають бути адресовані вашому безпосередньому керівнику чи замовнику. А ваші припущення мають бути затверджені. Вже з інтернатури деякі завдання передбачають додаткові запитання від виконавців.
- Частіше просіть відгук про виконану роботу. Здебільшого ми розробляємо додатки без інтерактивних прототипів. У нас є лише макети для одного (рідше декількох) станів сторінки. Тож сам процес взаємодії користувача зі сторінкою часто викриває нюанси, які не були враховані на статичному макеті. Просіть відгук на частково готові фічі ще в процесі роботи. Не чекайте до останнього, коли вже не буде часу щось змінити.
Post A Reply