Комунікація в команді (це важливіше, ніж ваші інструменти)

Після залучення кількох підрядників інші задають таке запитання:

oЯк це перейти від самостійної роботи над проектами до роботи над проектами з командою?

Або, простіше кажучи, як це мати підрядників? Коротка відповідь полягає в тому, що я це люблю, тому що це дає деякі переваги:

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

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

Як почати з чистого аркуша.

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

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

Командне спілкування

Очевидно, ця конкретна тема широка, і я, як і багато з вас, міг би говорити про різноманітні речі, пов’язані з веденням бізнесу.

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

Ваші інструменти важливі (але не настільки)

Наприклад, я працював там, де вам принесли машину з певним набором інструментів і сказали: «Це те, що ми використовуємо для створення наших проектів».

Звичайно, це вимагає, щоб ви навчилися цьому, але частково мені це сподобалося, оскільки воно усуває головний біль, який виникає, коли з’ясовуєш, що використовувати. Це також завадило мені приймати ці рішення самостійно.

З іншого боку, це також ускладнило впровадження нового інструменту, оскільки це порушило б робочий процес цілого відділу. Однак коли ви невелика команда, трохи легше пристосуватися.

Visual Studio Code став моїм улюбленим IDE.

По-перше, коли ви працюєте на себе, ви, ймовірно, маєте свій улюблений:

• ЙДЕ
• система контролю джерела,
• будівельні інструменти,
• засоби розгортання,
• хостингове середовище,
• і так далі.

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

Це не тривіальний спосіб, особливо коли ви працюєте один з одним, щоб знайти рішення для клієнта. Я міг би написати про це набагато більше. І не зрозумійте мене неправильно: я вважаю, що це тема, яку слід обговорити, і це те, що я вважаю важливим.

Але є те, що стоїть над усім цим, що ніколи не слід недооцінювати, і це процес командного спілкування.

Спілкування має значення (і більше)

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

Командне спілкування — це більше, ніж Slack.

Я говорю про вимоги повного спілкування.

Приклад: скажімо, я розмовляю з клієнтом, приймаю контракт і готовий рухатися вперед. Я знаю, чого вони хочуть, існуючі проекти та як щось має працювати. Тоді я приводжу товариша по команді та кажу: «Гей, давай почнемо».

Проблема тут зрозуміла, чи не так? Він/вона поняття не має, що ми прагнемо.

І не має значення, скільки ви окреслюєте кроки у своєму інструменті управління проектами чи балакаєте про те, як щось має працювати.

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

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

Це не можна недооцінювати.

Якщо ви знаєте вимоги, а ваш товариш по команді – ні, або якщо вимоги не чітко повідомлені з тієї чи іншої причини, належне рішення не буде надано. А це, очевидно, дорого коштує.

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

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

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

Буде більше

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

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

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