Стаємо професійними PHP розробниками. Частина 4: Робота в команді на практиці

Пропоную вашій увазі переклад четвертої частини циклу статей «Becoming PHP professional».

» Перша частина. «Відсутня ланка»
» Друга частина. «Важливість інших людей»
» Третя частина. «Робота в команді»

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

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

Різниця часових поясів та інші перешкоди
Коли у вас в команді є люди, які працюють віддалено, різниця в часі через часових поясів може бути величезною перешкодою. Взяти, приміром, SitePoint — я пишу для аудиторії, яка, в більшості своїй, США, тоді як головний офіс порталу знаходиться в Австралії, а сам я — з Хорватії. У результаті ми маємо 3 різних часових пояси, різниця між кожним з яких становить ~6-8 годин, з-за чого іноді ви можете отримати відповідь на ваш e-mail лише через добу.

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

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

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

Всі ці проблеми можуть уповільнити розробку продукту, так і зовсім зупинити її, але є кілька шляхів їх рішень. Розділимо їх на «органічні» та «неорганічні».

Органічні рішення
Як вже згадувалося в попередній статті, важливість компетентного керівника і менеджера (т. зв. «фільтра») не можна недооцінювати. Компетентний керівник здатний формулювати завдання належним чином і ділити їх на більш дрібні підзадачі, у той час як фільтр піклуватися про те, щоб до розробників доходили лише осмислені і необхідні задачі. Роль фільтра полягає в зборі завдань і в тому, щоб бути єдиним засобом комунікації між розробниками та іншим персоналом (або клієнтом). Його компетентність безпосередньо впливає на час подолання синдрому «пережатої горлечка».

Ви можете допомогти вашому менеджеру — відмовляйте людям, які не відносяться до процесу розробки проекту, з їх проханнями та дорученнями. Навіть якщо вони були схвалені СЕО, порадьтеся з технічним директором (СТО), тимлидом або керівником проекту, перш ніж приймати рішення. Вони, звичайно, ближче до людей, які потребують необґрунтовані і не виходять за терміни речі, і можуть «задушити» їх ідеї в зародку. Не відмовите один раз — не відмовите ніколи.

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

Неймовірно корисним буде також мати декілька годин в запасі. Планування вашого робочого часу таким чином, щоб у вас було як мінімум 2 години в запасі для ваших розробників, а особливо, для тимлида, є дуже важливим моментом. Це дозволить вам зустрітися з командою наживо або ж провести відео — або аудіо-дзвінок для обговорення. Одна картина коштує тисячі слів, один дзвінок коштує тисячі електронних листів. Дзвінок допоможе вам розпланувати свій день, з'ясувати всі незрозумілі моменти за завданнями, знайти найкращі шляхи їх рішень, а також допоможе поліпшити ваш рівень англійської.

Неорганічні рішення
Під даним типом рішень я маю на увазі деякі програми та веб-сервіси, про які хотілося б розповісти докладніше. Список ні в якому разі не є повним, але я використав більшість, якщо не всі, з цих інструментів, і я б не став рекомендувати нічого, з чим не працював сам.

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

Basecamp — популярна альтернатива Trello, і являє собою командно-орієнтоване TODO додаток. Як і в Trello, тут є обговорення, вкладеність завдань і завантаження файлів. Однак, Basecamp не безкоштовний.

Google Apps (GSuite) може служити хостом для вашої корпоративної пошти і надає закриті Google Docs і Google Drive корпоративні акаунти, а ще — груповий чат, Google Groups, корпоративний календар і багато іншого. Мені б хотілося, щоб більше компаній користувалися Google Apps. Більш того, бізнес-версія Google Apps підтримує Hangouts, а значить, ви можете миттєво обмінюватися повідомленнями зі своєю командою як з вашого комп'ютера, так і за допомогою смартфона. Приміром, Hangouts дозволяє вам приймати відео-дзвінки з двох пристроїв одночасно. Наприклад, якщо ви взяли відеодзвінок в п'яти хвилинах ходьби від офісу, а потім добралися до свого робочого місця, ви можете просто натиснути на «Приєднатися до цього дзвінком» і прийняти дзвінок з вашого робочого комп'ютера. Все це дозволяє вам зробити вашу комунікацію в команді по-справжньому професійною.

FlySpray — супер-простий open-source баг трекер, який допоможе вам відстежувати дрібні баги в повсякденній роботі. В мого минулого компанії, ми дозволяли нетехнічних людям надсилати запити та повідомлення про баги за допомогою FlySpray, а потім фільтр відкидав безглузді повідомлення і описував справжні баги більш докладно. Так, ми завжди отримували повний звіт, який дозволяв нам набагато швидше відтворювати і виправляти баги.

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

У Atlassian, творців BitBucket, також є безліч інших інструментів для командного взаємодії, наприклад, Confluence і JIRA, які дозволяють працювати з вашою командою в реальному часі і зберігати всю інформацію в одному місці. Jetbrains також пропонують непоганий набір інструментів: TeamCity (з безкоштовним професійним виданням) для безперервної інтеграції і YouTrack (60-ти денний пробний період або безкоштовна версія для 10 користувачів) для відстеження помилок, проблем і запитів.

Якщо ви дотримуєтеся гнучкої методології розробки (Agile Development), кращими платними інструментами є PivotalTracker і GreenHopper (плагін для JIRA). Обидва інструменти мають і безкоштовні версії.

Остання, але не менш корисна річ, яка допоможе вам складати TO-DO списки — це Todoist (яким я користуюся кожен день). Інтерфейс прямолінійний і сфокусований на самих завданнях. По суті, в ньому є все, що ви бачили у подібних програмах, але зі значними поліпшеннями.

Якщо ви розробник, я рекомендую вам користуватися Github і TeamCity, а також використовувати Trello для обговорень. Якщо ж ви менеджер і займаєтеся підтримкою проектів, то я дуже раджу вам використовувати Google Apps. Якщо ваша команда використовує методологію SCRUM — PivotalTracker вам в допомогу.

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

А чи є у вас улюблений інструмент для командної взаємодії? Як ви вирішуєте проблеми в своїй команді?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.