Що може допомогти менеджеру проектів у роботі з програмістами

Попередня стаття була досить популярна. Я обіцяв продовжити і тримаю слово. Ділюся своїм особистою думкою і не претендую на істину.

У цій частині йтиметься про роботу з програмістами.



1. Замість милиць потрібний фундамент. Люди, а не методології
З досвіду впроваджень різних методологій Agile зробив наступні висновки
1. Цілком зрозумілим удаваним рішенням багатьом здається використання типових рад. Віра в срібну кулю, джина з пляшки властиве більшості людей, менеджери проектів — не виняток.

2. В останні роки популярним распиаренным рішенням стали всілякі гнучкі методики, про які не писав тільки ледачий. Про це якості людей докладно нижче.

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

4. Як відповідь розробників на все це, з'явилися знаменитий англійський маніфест «Programming, Motherfucker! Do you speak it?» і його російська варіант.

5. У кінцевому рахунку, вода камінь точить. Не буду стверджувати, що методологіями в стилі «витратимо час на [censored] балаканину» програмістів дістали, але якась частка впливу тут є. Найбільш рутинні шматки в розробці стандартизовали і автоматизували — і все частіше стали з'являтися прекрасні статті від Яндекса, Badoo і так далі, як збудований процес розробки. Де велику увагу приділено технічних інструментів, які реально роляют на процес розробки, на відміну від нескінченних танців з бубном.

Хочу зазначити, що з програмістами, які розумні і хочуть працювати, досить легко взаємодіяти. Ви пояснюєте людині, навіщо потрібний функціонал, і обговорюєте user stories. Якісь архітектурні моменти. І далі людина реалізує те, що потрібно, точно і красиво.

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

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

2. Управління вимогами і вхідними даними як ефективний засіб спрощення завдань
Хочеться відразу відзначити, що я не вірю в теоретичні знання. Можна прочитати сто книжок і здати на PMI, MBA і безліч інших слів, але завалювати всі проекти. А можна і робити проекти, як пиріжки, не володіючи цінними «знаннями».

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

Кейс 1. Робиться розсилка e-mail листів, посилання у яких веде на лэндинг. Постає завдання у молодого менеджера проектів, обмежити від спаму форму на лэндинге.
Береться приклад у іншої робочої групи, як зробити такий захист на 8+ годин.
І тут приходить більш досвідчена людина, і пропонує уважно вивчити початкові умови. Лэндинг призначений тільки для відкриття з поштових листів.
Отже, у першій версії досить в посиланнях з листів ставити якийсь ключ в URL, який буде викликати показ форми на лэндинге. А при прямому заході форму не показувати.

Придумати — одна хвилина, робити — 15 хвилин. Проти 8+ годин. Без коментарів.

Кейс 2. Звертається до мене менеджер проектів. Потрібно, мовляв провести опитування на проекті. Був якийсь движок опитувань, можна прикрутити, або писати свій.
Послідовно задаються питання
— Скільки разів потрібно проводити опитування? Відповідь: один раз
— Чи будуть змінюватися поля: Відповідь: ні, не будуть.
— Скільки бере участь у опитуванні користувачів. Відповідь: десяток.

Через хвилину видаю рішення — зробити форму на Гугл Докс, і поставити на проекті посилання. Реалізація хвилини, проти днів на прикрутку движка опитувань, налагодження, винесення на реліз і так далі.

Сюди ж відноситься і занос контенту статикою (HTML), якщо він не змінюється частіше разу на місяць, замість створення движка і WYSIWYG, і багато інших речей.

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

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

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

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

Це можливо, але для роботи з талантами, мені здається, не дуже підходить.

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

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

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

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

4. Не йдіть за всіма — це нерідко закінчується провалом
Степан Демура, неоднозначний, але яскравий трейдер якось сказав, що якщо ви будете стояти на ринку, так само, як і натовп, то ви обов'язково програєте.

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

Ми колись, як і все, кинулися робити міський портал. І були побиті конкурентами. Хоча, здавалося б, все роблять, і у всіх повинне вийти.

На жаль, є проста аналогія, яка говорить, що ресурсів майже завжди менше, ніж їх потенційних споживачів, і має місце конкуренція.
Ось стоїть намет з молоком, і в день ходить 100 осіб. Намет успішна, і з'являються конкуренти 2,3,4,...N. А як ходило 100 осіб, так і ходить. Але прибуток кожної зменшується з появою нових, і в кінцевому підсумку розоряються всі (один з варіантів сценарію).

Ось так і відбувається з новими нішами в бізнесі (згадайте ті ж купонаторы).

Є й інший приклад, де дана рекомендація працює трохи інакше.
Вчора всі сидять на NoSQL, сьогодні пиляють на jQuery, завтра SVG+HTML5, післязавтра 3d для FaceculusRift.

У підсумку, слідуючи за модою на технології, ви отримуєте проект-зоопарк, де дружити технології все важче і важче. Прикладів багато.

В протилежність один відомий сайт бронювання готелів, що працює на [censored] мамонтів Perl. Я на Perl не писав вже років 10, і все чекаю легендарного Перла 6. Офігенний мову був (і залишається). Наскільки я знаю, їжачки колються, плюються, але продовжують жерти кактус. І проект росте і розвивається, не страждаючи від різкий падінь «а потім ми переписали все на Джаві (підставте ваш язик) і купили ще 1000 серверів, щоб не падало щогодини».

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

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

5. Навчитеся програмувати
От кажуть, що рибак рибака дізнається здалеку. Навіть якщо ви нічого не прочитали і просто прокрутити вниз, ви вже отримаєте користь.
Якщо ви навчитеся програмувати, то обійдете сотні тисяч молодих хлопців і дівчат, хто мріє про високу зарплату в IT, але хочуть тільки керувати.
Бо своїх люблять і визнають в будь-якому середовищі, а якщо керівник програміста технічно підкований, то це дає +1000 (ІМХО) до скиллу поваги.

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

Докладу хорошу посилання (ще одна) і ролик видатних і відомих людей, чому вам варто навчитися програмувати.



В коментарях пропоную поділитися своїми знахідками з досвіду, якимись кейсами, які вважаєте цікавими.

Джерело: Хабрахабр

0 коментарів

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