Сім смертних гріхів у наймі. Досвід Djinni

На обговорення цієї теми мене надихнув твіт Джейсона Лемкіна: «Майже всі важливі помилки, які я зробив за останні 15+ років, були наслідком того, що я занижував планку прийняття на роботу».

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

Disclaimer: Тут і в випуску подкасту описую лише мій власний досвід з Djinni, не претендую на істину.

У моєму списку вийшло 7 пунктів, тому я назвав його «Сім смертних гріхів найму». Поїхали.

Fuzzy role

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

Як цей «гріх» вирішити: запитай себе, як має виглядати «успіх» цієї людини в цій ролі за 7/30/90 днів? Визнач це приблизно як «definition of done» в Scrum і для кандидата, і для себе.

Unicorn role

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

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

Culture fit

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

Мова про те, що потрібно розуміти culture fit команди (і чи підходите ви одне одному) до початку роботи, інакше можна розчаруватись і витратити час — і свій, і команди — дарма.

Як я визначив culture fit для Djinni? Намагався подумати про тих, хто має найкращий досвід роботи в команді — наприклад, отримував промоушн, а також про тих, з ким ми попрощалися з тих чи інших причин.

Також запитав у самої команди, і з цього усього синтезував загальні речі. Це такі пункти:

  1. Ставлення до роботи. Є два типи людей: з внутрішньою мотивацією, коли робота — важлива частина життя і реалізації (не плутати з трудоголіками), і ті, хто сприймає роботу як вимушену штуку типу «треба пересидіти цей день і піти займатись своїми справами», працюють тільки тоді, коли є тиск зовні. Це більше залежить від людини — чи вона перероблює задачу, бо відчуває, що може краще, а не тому, що ти їй так сказав. Ми — про перший тип.
  2. Remote. У нас більшість питань обговорюються асинхронно, багато текстової комунікації і мало мітингів.
  3. Self-management. Якщо ти пообіцяв щось — ти це зробиш, не треба нагадувати кілька разів і уточнювати статус задачі.
  4. Results (not efforts). Деякі люди вважають, що якщо вони хоч і не вирішили задачу, але витратили на неї час — це ок. Я принципово з цим не погоджуюсь. У нас немає чіткого графіку роботи, не контролюємо час. Важливо не те, скільки часу ти працював, важливий результат: зроблено чи ні.
  5. Ownership. Якщо ти відповідаєш за задачу — то від початку до кінця. Вирішення задачі повністю на тобі.
  6. Проукраїнська позиція. Місія Djinni — заробити хуліард дєнєг для армії та відбудови України.

Більше про culture fit для Djinni — в окремому епізоді подкасту Startups are hard.

Waiting too long

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

❗️ Не можна ігнорувати будь-які сигнали, які кажуть, що тут щось може бути не так. Починай розбиратися одразу.

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

Якщо ловиш себе на думці «треба більше часу» — не треба. Прощайтеся негайно, краще вже не буде.

References

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

«Навіть не думай, бери, не пошкодуєш» — це єдиний варіант, який має рахуватися, як нормальний референс. Всі інші варіанти «із зірочкою» або з формулюванням «так, беріть, але» — це сигнал зупинитися.

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

Правда, ідеальний референс — теж не панацея. У нас був найм кандидата, якого мені дуже хвалили за рекомендаціями, і він все одно не спрацював. Помилки будуть, але дивись пункт вище — don’t wait too long.

Mentoring & support

Яку б класну і досвідчену людину ти не взяв, це ще не гарантія того, що вона буде успішна саме у твоїй команді. Їй для цього потрібна і твоя участь, допомога і підтримка. І я не маю на увазі hard skills — не треба вчити людину, як виконувати роботу.

Щоб людина стала успішною саме у твоїй команді, їй потрібен контекст: що ми робимо і для чого; що означає «успіх» для компанії в цілому та на її ролі в ній. Комунікація твоїх очікувань. Пріоритети і те, що у нас важливо або, навпаки, неважливо. Знайомство з командою.

І я тут не маю на увазі один онбординг кол або «іди почитай наш Notion». Це процес. Щотижневі дзвінки, щонайменше. Плюс, підтримка і відповіді на запитання в чаті.

Ще важливо, що є тонка межа між «допомагати» і «не заважати». Про це теж треба пам’ятати.

Don’t forget the candidate

Чому людина вирішила доєднатися до команди? Що її хвилює? Які цілі або побажання у неї щодо роботи? Що для неї важливо в житті та в роботі?

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

Складно побудувати довгострокові відносини, якщо цієї взаємності немає. Найняти людину — це не купити інструмент або сервіс. Люди — не машини, їхня ефективність в команді — нелінійна.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось41
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую, багато чого перетинається з моїм досвідом та думками

«Навіть не думай, бери, не пошкодуєш» — це єдиний варіант, який має рахуватися, як нормальний референс. Всі інші варіанти «із зірочкою» або з формулюванням «так, беріть, але» — це сигнал зупинитися.

Ця рекомендація протирічить «гріху»

Unicorn role

Тобто, шукаємо ідеального кандидата з ідеальним референсом. Крім того, референси про різних кандидатів надають різні люди, у кожного своя шкала оцінювання і своя мотивація говорити чи не говорити правду. Ще буває просто застаріла інформація. Звичайно, якщо вдастся зібрати 3-5 референсів на кандидата, і в кожному буде що він мудак, то це скоріш за все і на інтерв’ю не уникне уваги.

Ownership.

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

З володінням — палка о двох кінцях. IT-проект то не злиток золота, він не може просто лежати доки ти ним володієш. Це скоріше як сад, яким лише формально володіє власник маєтку — але ілюзія володіння швидко зникне, щойно він звільнить садівника.

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

тут ownership as a skill, це просто одне з тлумачень
„Ownership is taking the initiative to bring about positive results”

Тут цікава справа — у кожного своє бачення позитивного результату. Скажімо у якогось власника бізнесу, це може бути — усе продати чи вийти на IPO. На виручені гроші купити якусь крутезну тачку, яхту, будинок та просадити решту із дівчатами, алкоголем та кокаїном де небудь в Маймі Бічь чи Вегасі. А контора з людьми які на цей результат в’ябували подекуди ночами та віхідних, нехай йдуть в датасайнс джуни перекваліфіковуются чи кричать вільна класса. Всеодно лохи, що з них — убогих. У якогось інженера в свою чергу може бути — набратись досвіду, відкрити на пару з клієнтом власну контору та забрати усіх людей і експертизу, тобто кинути першого, всеодно дурний та жадібний козел. Світ мотивації не обмежений. Скажімо у Елона Маска мотивація, екологічний транспорт та пілотований пілотований політ на Марс.

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

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

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

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

дати обом по менті, а потім ще по одному

Не зовсім зрозумів куди саме дати. По яйцях?

Якщо серйозно, то не варто робити головним у всьому. Достатньо нерівномірно розподілити зону відповідальності. Тому до «автоматично» не доходить, там досить великий поріг толерантності. Хіба що там сильно запущена зіркова хвороба — але в такому разі варто втратити хворих, і треба докладати зусилля по їхній заміні.

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

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

класика жанру для недорозвинених країн — це небажання знати, а хто взагалі потрібен

Тут якраз карїна нідочого, таке я бачів: і в Англії, і в Угорщіні, і в Канаді, і в Фінлядії, і в Сполчуених Штатах і в федерації (до 14-го року). Недосвічений менеджмент, terra incognita. Нема BA або BA це хто завгодно а не бізнес аналіст, нема тех.ліда (архітектор) або це хто завгодно тільки не архітектор, нема ані прожек — ані продукт менеджера, або це хто завгодно тільки не вони, нема тестувальникив або це хто завгоднго тільки не вони — от і маємо. Тому контори по більше і вибудовують процесси (хоча як виявилось кожний акаунт вибудуовує свій власний) , щоб принаймі базовий стандартний набір спрацьовував і давав відворення результату. Чому мені пдобаються SAFe та Scrum? Це такий загальний стандарт який каже, принаймі загально — як має бути побудована софтверна команда, які в ній ролі і хто за який процесс відповідальний. Коли невідомо, що влесне треба зробити, а зазвичай так і є, люди на своїй позиції починають це з’ясовувати. Product owner бере на себе вимоги та backlog, scrum master організації процессів, техлід процеси: проектування, стандартів розробки, зміни пріоритетів від бізнесу тощо, тестлід тестову стратегію. А далі ці люди вже самі знайдуть хто Їм ще треба, як роботи багато і делегувати потрібно, та є можливість пояснити decision maker що на це треба бюджет. DevOps, DBI, UI/UX, release engineer, сініори, мідли, джуни в джуніори в менті сініорам тощо.

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

Це напевно тому, що така була тема епізоду. За 10 років були звісно невдалі найми, але вони в меншості.

Тобто виходить наймати абсолютну більшість людей, що відповідають усім критеріям? Дуже класно тоді(:

Results (not efforts).

Тут может быть не все однозначно и больше зависит от того как это будет преподносится самим кандидатом.
Например решили сделать какой то сервис который должен работать быстро. Выбрали библиотеку а она не подошла. Переключились на другую и вылезли за рамки. Вроде как результат не очень.
Если поставить задачу как подготовить PoC с несколькими подходами. Описать что получилось и потом выбрать нужную библиотеку времени займёт наверное даже больше но зато результат отличный на каждом этапе . И явно измеримый. Если работник сам может все эти задачи себе ставить он учтёт это.

Тоже палка о двух концах, пока вы там делаете на рызных фреймверках течет время, а вместе с ним и косты — ваша зарплатта, зарплатта коллег, девопсов, тестировшиков, бухгалтеров и т.д. сервера, электроэнергия, офис (если есть) и т.д. У высконагруженых проектов где вытащить из оборудования максимум это приоритет — такой поиск оправдан, и НИОКР-ы разные с прототипами, бенчмарками и прочими эксперементами. Однако в 50-80% оно не надо, а надо чтобы можно было подстраивать под нужды бизнеса — тоесть зарабатывания денег. Вот в таких случаях разная унификация вроде спрингбутовых микросервисов со стандартной з-х уровневой архитектурой, готовых ecommerce фреймверков, CMS и т.п. и срабатывает. Сильно дешевле выходит чем процесс свободного поиска. Однако бывает и частенько и обратное, когда начали с базового решения но в процессе развития и решения и самого бизнеса уперлись в возможности и ограничения самой платформы.

отрицательный результат, в книге гугла по SRE описан. И он по сути является тоже результатом, даже исходя из названия, но если он задокументирован. Иначе это просто усилия, так что никаких противоречий.

Я это понимаю. Зависит от того что делать с полученными знаниями. Непонятно что имеется ввиду в статье и будет от такой результат принят.

Статья с позиции единорога, который может неограниченно хайрить и увольнять.
На практике и репутационно, и для проекта может быть лучше оставить сотрудника, работающего на 50% мощности или предметной области, чем искать идеал, ждать пока он вникнет в проект (и все равно не достигнет такой глубины, как старожилы), а потом — уволится, потому что хочется чего-то нового.

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

Тут идет подача, что хозяин конторы идеально в деталях понимает, что нужно сделать в будущем. Как минимум, в разработке софта не так — поэтому водопад и помер — и пришли к итеративным и гибким способам. То же с наймом.

С позволения сказать водопад не помер, полностью по крайней мере. Чаще всего его называют agile теперь :) А те кто в теме fragile или srumban или срам. Скажем заходиш на проект, тебе сходу у нас agile и scrum. а что там внутри — fixed price, диаграма Ганта, эстимейт в часах/днях/мифических человеко месяцах иерахическая система управления, даже структура размалевана, причем ещё и единоначалие нарушено по этой структуре. Авто тесты, юнит тесты делать мы не будем, CI/CD по остаточному принципу абы выглядело что работает чтобы клиенту показать какие мы молодцы, смена требований заказчиком в контракт не включена. Срочно-блть-3.14здец-ААА!!!. Если по пытаться что то изменить следует коронная фраза от менеджера, причем несколько раз слово в слово. «У меня сложилось впечатление что ты никогда не принимал участие в Agile проектах». Впрочем если молодые ещё изменить можно иначе нафиг надо, это гиена — а не процесс. Тут все кончится бесплатными овертаймами, психологическим прессингом, скандалами и бессмысленным героизмом. Ноги в руки и дальше.

Статья с позиции единорога, который может неограниченно хайрить и увольнять.

Вполне логично: когда команда небольшая — то важно что бы это были не только профессионалы, но и энтузиасты. Хорошо находить людей, которые привносят что-то полезное.
Есть деньги — вложи их в найм лучших людей!
А «балласт» на 50% мощности — это больше подходит для галер и «бесконечных» легаси проектов.

Тоесть вы за то чтобы поставить свои бизнес, как источник денег и следовально средство к существованию себя своей семьи и на чуваков которые будут держать в своей голове все и херачить с утра до ночи ? Что тогда будет когда эти эти чуваки уйдут или у них возникнут неизбежные при таком подходе проблемы со здоровьем и профессиональные заболевания ? Всех простых людей которые живут нормальной жизнью — вы тут же выбрасываете за борт, даже не давая им шанса проявится. Тут отсается цитировать Масааки Имаи и базовый принцип Кайдзен (а на японской ситеме менеджемента, на самом деле и базируются гибкие подходы). «Японский рабочий ничем принципиально не отличается от скажем австралийского, но его более умело направляют и лучше управляют» youtu.be/plHd10m6QNk?t=835 Если глянете фильм Moneyball en.wikipedia.org/wiki/Moneyball_(film поймете весь принцип сразу. Подход рокстаров в раельности тупиковый, скорее всего на первых же этапах когда по теории должен возникнуть кофликт интересов — эта вся команда рокстаров тут же и развалится.

Тут про тот самый Culture fit. Если у тебя есть идея и ты ей «горишь» то ты будешь набирать в команду тех, кто то же на данном этапе жизни заинтересован «творить» и горит энтузиазмом. Это не обязательно значить ебошить по 12 часов без выходных а потом сдохнуть. Как говорится «работать нужно не 8 часов — а головой». Сейчас очень многое можно реализовать с минимумом или вообще без кодинга. Но нужно иметь желание пробовать новое, вникать, экспериментировать.

Что тогда будет когда эти эти чуваки уйдут

На каком-то этапе это неизбежно случится! Это то, к чему нужно быть готовым. Человек хорошо работает пока ему интересно. Со временем стартап может вырасти и станет больше рутины или кого-то привлечет более новая идея. Есть люди, которые умеют стартовать новое — но как только оно уже не новое — идут дальше. И тогда им на смену приходят:

Всех простых людей которые живут нормальной жизнью

И которые будут дальше поддерживать и развивать этот проект по 8 часов в день.

Подход рокстаров в раельности тупиковый, скорее всего на первых же этапах когда по теории должен возникнуть кофликт интересов — эта вся команда рокстаров тут же и развалится.

Такую команду собрать непросто. И еще сложнее удержать. Я видел один позитивный пример, когда сыгранная команда профи делает проекты под заказ. Но они всегда берут проекты не больше года длиной и по готовности передают другой команде — на сапорте не сидят.
У них есть стимул: вместе быстро сделали проект — поделили хорошие деньги, потом могут отдыхать до следующего.

Ну вот посмотрите тот видос с книгой или прочтите книгу. Как раз станет понятно что вся система сделана так чтобы людям было интересно было делать их работу, а не бегать между конторами на +500. В реальности подавляющему большинству людей на работе интересно работать, а тем более в ИТ, иначе вообще не нанимались бы тогда. Никто ведь силком не заставлял посылать резюме и идти на собеседование, не так ли ? Однако система где все настроено на индивидуальный личный успех одного человека или ограниченной группы людей, вместо успеха всей компании, как правило приводит к неудовлетворённости человека его работой и в итоге уходом. Тогда как, если вовлечены даже люди с казалось бы простейшей работой, будь то официантки — никто не уходит, все заинтересованные и получается экономический эффект. Пусть он даже не большой в рамках столовой, но он есть и в целом по конторе может оказаться вполне себе существенным если сложить все вместе. На выходе получается : Toyta, Toshiba, Mitsubishi и т.д. Lexus может и не Bently, но это Lexus — а не скажем УАЗ. Все хорошие agile тренинги на которые я попадал, а это в основном за границей было, сразу упоминают от куда взялись гибкие подходы в ИТ и на чем это все базируется, зачем все это надо. Скажем зачем на ретроспективе рассматривать предложения, давать народу разные плюсики ставить против предложений и проблем, вызывать добровольцев (responsible person) которые возьмут ответственность за решение проблем и т.д. Или почему на стендапах люди друг другу слово передают или мячик кидают между собой, а не менеджер требует статус по задаче и дёргает тикеты по борде демонстрируя микро-менеджмент во всей красе и т.д. По той же причине, скажем этот самый стендап можно делать в любое рабочее время суток, скажем в конце дня вечером тоже можно, скажем если люди ходят на английский по утрам и т.д. и т.п. Вот что точно можно сказать изнутри модель не ставится практически, внешние консультанты нужны.

В реальности подавляющему большинству людей на работе интересно работать, а тем более в ИТ, иначе вообще не нанимались бы тогда.

Вы из какой страны пишете? На ДОУ постоянная тема про унылую работу на «галерах» и выгорание. Я уверен что 80% сотрудников «галер» (а это самые крупные конторы, «лидеры рынка») — не считают свою работу интересной и гребут за бабло.

Как раз станет понятно что вся система сделана так чтобы людям было интересно было делать их работу, а не бегать между конторами на +500.

Пример иностранных ПРОДУКТОВЫХ компаний не имеет никакого отношения к аутсорсу! Совсем другая модель прибыли, совсем другой подход к кадрам, совсем другой уровень проектов.

Продукт содается в любом случае подрядным способом и сторудниками в штате. В Японии жизнь тоже не бесплатная, более того крайне дорогая, поэтому за денги в общем то гребут так или иначе все. Смысл крадинально в другом, другая философия и система ценностей. Западная система ценностей направленна на личное достижение индивидуального человека, скажем на единичного форфарда который получит золотой мячь и контракты с рекламодателями. И это при том что играют в футбол команда на команду. В редких случаях работает как скажем с Роналду и то сильно не сразу, думаю потому что он тренеровал свою команду. А вот успехи зборной Аргентины не очень, несмотря на то что там играл Месси — а тренером был Марадонна. Японская и в целом восточная система ценностей направленна на достижения коллектива, тоесть не важно кто и сколько голов забил если мы по итогу продули матчь, кстати, как и рання советская до застоя. Наши галеры тем и интересны, что это удаленная работа на иностранные компании со всего мира. Можно посмотреть как люди там работают и подсмотреть для себя рабочие вещи. Можно потом, консультировать и других клиентов, вот смотрите работает вот так вот — использовалось там то и теми то, давайте и тут такое сделаем.

Можно посмотреть как люди там работают и подсмотреть для себя рабочие вещи.

Смотрел — рабочие вещи в аутсорс не отдают!
Думал что в MS все делают по MSF (en.wikipedia.org/...​osoft_Solutions_Framework), по книжкам — а хрен там! Ковбой — кодинг в чистом виде, еще и разные команды (индусы, украинцы) — каждый что-то пилит, никто ничего не понимает, никакой синхронизации. Поэтому и отдали этот кусок аутсорсерам — потому что это «мертвая лошадь».

Можно потом, консультировать и других клиентов, вот смотрите работает вот так вот — использовалось там то и теми то, давайте и тут такое сделаем.

Каждый раз стараемся предложить клиенту делать по-уму. И в 90% случаев он хочет тяп — ляп — и в продакшин! Опять же: от аутсорсеров не ожидают что они синхрофазотрон сумеют собрать — отдают то, где качество не важно.

Раз вам перекинули какую то работу — значит она есть, за нее готовы заплатить тоесть то что вы делаете кому то нужно. У продуктовых команд частенько другая проблема (плавали знаем) то что вы делали по итогу никому не надо. То что клиенту не получалось показать на числах и репрезентатывных документах с графиками и т.п. почему так выходит и наглядно продемонстрировать лицам принимающим решение, что ляп-ляп и в продакшн им обойдется сильно дороже — тут конечно сами не сумели. Однако все что касается менеджмента, тут да — как исполнитель хрен вы сами чего сделаете, третью сторону надо звать которая процессы ставит. Когда третья контора аджайловодов заходит и ставит процесс, за этим даже наблюдать интересно. Причем реально выходит, на разных PI которые фасилитирует третья сторона, соседние команды могут поделится бюджетом и решить проблему старательно скрываемую менеджершой от начальства и от своих людей — атсурсеров, коих уже собралась увольнять как платить нечем. Пояснить ЛПР-ам что не может быть приоритет десять у всех десяти фитчь, что бюджеты стоит равномерно распределить — а не скажем все отдать в UI так как это важно с точки зрения бизнеса и т.п. Там же и в обмороки падают и когда вскрываются более реалистичные временные и финансовые затраты и т.д. — кстати прямое следствие другой системы ценностей. Как уволить кучу народу коих собирали годами и готовили — так без проблем, как показать начальству что не можешь справится и есть проблемы — караул! Конец карьеры, это теперь — уволят или на повышение не отправят. Причем во втором случае проспав сроки и бюджет, как раз начальство максимально и подставляется, сообщи вовремя о проблемах будут решение искать, могут денег найти, могут пересмотреть все что делается и отказаться от не нужных фитчь заказанных «на вырост», и т.п. А так знает что не выйдет но молчит до последнего, авось пронесёт по овертаймим бесплатно и зайдет.

Так, так. До якого із цих пунктів належить найм девопса на джин на $15K/міс.?

Waiting too long

Це дуже вигідно усім, крім нащадків. Їм це все розгрібати

Так, це перше, про що я подумав =).

До прибутковості самого джині :) Це ж звичайнісінький маркетинг. «Йдіть до нас і отримаєте в чотири рази вищу зарплатню за середню по Українському ринку». Те саме різні: Turing, Kimberly group, linkedin тощо. Пропонується прямий контракт без посередників, а коли наймає контора десь із Сан-Франциско на тимчасову роботу рік-два, то 15 баксів на місяць для них ок на справді. Та і галери не будуть заважати та казати, як менеджер нормальний, що чуваку не завадить спати по ночах, мати вихідні, мати відпуску, підвищувати кваліфікацію тощо.

Чим більше в нас буде наймів на 15к тим більше зможемо вкладатися в команду і продукт. ;-)

Є ще декілька речей які як на мене є стадією не повного розуміння. Перший це ownership — коли ви граєте в команді так не працює, що одна людина повністю відповідає за якусь задачу. Тут треба грати в пас, а задля цього треба від початку знати хто і за що відповідає, умовно хто на якій базі стоїть, що там робить. Скажімо за вимоги відповідає BI, за розробку программіст, за тестування — тестувальник, а за білди та деплоймент чи реліз — девопс, за бізнес і валідацію і верифікацію та що усе це реалістично і зроблено в строки та бюджет — продукт менеджер (delivery manager, product owner etc), а за те щоб усі процеси працювали і не буксовали — прожект менеджер (scrum master). Яким би сініором хтось не був, може відбутись факап і цей факап треба вчасно спіймати і закрити, допомогти де треба тощо. Можна різними методами це все покрити, наприклад бігати між столами як це відбувалось коли були опенспейси, але процедури з Agile: kik off за процедурою де людей знайомлять один з одним пояснюють їх ролі, стендапи а не статус мітинги, kanban бороди, risk management, backlog grooming, planing, 3 Amigo, demo тощо. Такий процесс справді мотивує людей і робить їх ефективними, чисто психологічно вносить групову динаміку і ігрові процеси в таку доволі не іграшкову річь як робота. Якщо процесс збудований не погано, то і сенсу міняти людей в ньому набагато меньше більше за те вони підтягуються і навчають один одного, та і сарафанне радіо розносить швидко — що там от круто працювати, там весело і люди класні, навіть якщо навколо величезна галера з погонщіками і плітьми де кадри течуть рікою і пів бюджета тоне на HR та підготовку джунів. Дійсно буває що хтось не тягне в команді через помилку найму, скажімо десктоп чи мобайл чувака вийняли в веб проект, а там взагалі невідомо — що робити, строки горять і нема часу чекати доки відбудеться перекваліфікація, чи якийсь п’яниця попався який на співбесіді нічого так, та й по життю веселий хлопець, а по роботі — з будуна постійно і тобі за нього робити пів роботи. А так виходе просто текучка кадрів і постійний пошук рокстарів, вигарають тільки рокстари в решті решт чи йдуть на +500 чи в MAANG готуються і як пройдуть полишать вас на одинці із вашим проектом прихопивши з собою експертизу.

Підписатись на коментарі