Як вам "продати" підтримку як варіант кар'єри [закрито]

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

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

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

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

Спроба найняти людей на роботу на підтримку штатного дня - це проблема. Застосувань мало, і калібр не особливо високий.

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

Не варто

Для мене найкращим варіантом тут є не розділяти розробників на підтримку та непідтримку насамперед. ІМХО є три основні причини:

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

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

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

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

Зробіть службу підтримки цікавою і корисною для своїх розробників.

Я люблю підтримувати наступні причини:

• Я розмовляю з людьми по всьому світу. Я зробив багато таких друзів . Кілька років тому один мій клієнт запросив мене на своє весілля! Я мав у своєму кабінеті карту світу з шпильками, які їх розміщували.
• Підтримка - це майже найкраще задоволення від вашої роботи. Коли ви робите користувачів щасливими, це теж робить вас щасливішими.
• Скарги - корисний спосіб покращити себе. Я будь-яку скаргу сприймаю серйозно, і в більшості випадків я можу перетворити когось розлюченого в щасливого клієнта / користувача, який врешті-решт поширить слово навколо.
• Це допомагає мені зрозуміти, що потрібно клієнтам / користувачам. Тоді я можу скласти краще програмне забезпечення.

Це лише кілька причин.

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

Коли ми отримуємо справу підтримки, ми робимо наступне:

• Якщо це помилка, що відтворюється, ми додаємо її у відставання та надаємо свій ідентифікатор замовнику / користувачеві. Ми також беремо ідентифікатор замовника / користувача, щоб повідомити його про рішення та звільнити його особисто. Це легко, якщо ви збираєте його електронний лист безпосередньо.
• Якщо проблема з використанням програмного забезпечення, ми використовуємо це як можливість вдосконалити документацію. Будь-яка відповідь пишеться як стаття бази знань, яку ми додаємо згодом у нашу базу даних. Для написання потрібен потрійний час, але ми не повторюємо пізніше (більшість користувачів віддають перевагу перегляду в КБ).
• Якщо це запит на функцію, ми безпосередньо підключаємо користувача до власника продукту. Це дуже цінно. Звичайно, ми використовуємо такі системи, як uservoice.com, але спілкуватися з користувачем безпосередньо набагато краще.
• Якщо це скарга, ми намагаємося керувати нею поза процесом. Люди, які скаргу люблять вважати важливою (навіть якщо скарга банальна).

Чому б просто не заплатити розробникам на 5 або 10 тис. Більше за збірку та забути розробники?

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

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

Зазвичай підтримка не сприймається так само весело, як нова розробка, і якщо у вас є окремі команди з розробки та підтримки, групи підтримки повинні приймати те, що дає їм розвиток, що часто не цікаво. (Я колись працював у місці, де науково-дослідні роботи надавали нам програмне забезпечення, яке робило щось круте, але для переробки дизайну, як правило, потрібна якість виробництва, і ми не отримали достатньо часу для цього з політичних причин. Це не було весело.)

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

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

Кілька думок:

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

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

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

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

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

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

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

Я думаю, що zappos.com показав, що робота не повинна бути лайна, коли ти працюєш у хорошій компанії. Найгірша частина бути підтримкою - це не в змозі комусь допомогти. Якщо ви накрутили користувачів на контракт на надання послуг з дрібного друку або відправлене баггі програмне забезпечення, яке незабаром не виправиться, підтримка буде вичерпана. Їх потрібно заохочувати до пошуку проблем; як програмування.

Я кілька років підтримував свою першу компанію поза коледжем. Що змусило мене зареєструватися на пару років:

1. Необхідний шлях кар'єри, щоб стати інженером-програмістом.
2. Мені знадобився час, щоб визначитися з основною мовою компанії (Fortran, Circa 1989)
3. Я не був одружений, тому міг би звільнитись, якщо виявив, що мені не подобається компанія чи робота.

Як щодо якоїсь суміші розвитку та підтримки (розділені ролі)? Думаю, ви все ще будете боротися за придбання для цього через причини, про які вже говорилося (розробники! = Люди, які підтримують продукт). Але якщо ваш продукт покладається на широке розуміння внутрішніх технологій, можливо, на 80% розвиток, 20% підтримка буде справедливим компромісом. Або якесь наставництво / тінізація для нових співробітників для того, щоб вони отримували правильну інформацію про товар.