Складні ситуації в IT, і що з ними робити?

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

Начальство

Зверху приходять вказівки:

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

Дуже грубо, причини чому начальство може давати дурні дивні вказівки:

низький IQ. Вкрай рідкісна причина, в айті ідіоти не приживаються, а PM «по знайомству» не стають;
мало знань у профільній області і немає вміння оточити себе експертами. Таке іноді буває, хоча досить рідко;
бажання проявити владу. Іноді буває, але все-таки рідко. Я, мабуть, лише пару прикладів можу навести за 18 років;
адаптація — суперэксперты звикають, що навкруги все розбираються дуже слабо. Тому звичніше сказати «зроби, як я сказав», ніж пояснювати, чому так. Кожному поясниш — а працювати коли?
мало даних і розуміння поточної ситуації. Ось це часта проблема. Гірше того, менеджери часто не розуміють, що даних мало, і воліють діяти. Що робити:
- задавати питання «а що будемо робити, якщо ось так і ось так?» Швидше за все, вам це питання і повернеться з формулирокой «швиденько подивися ось це, і давай ще подумаємо»;
- виводити на конкретні зміни в діях. Тобто якщо «ви повинні менше часу витрачати на саппорт», то «якщо я весь саппорт винесу на понеділки, це ок?».
менеджери, які виросли з програмістів, часто мають особливості:
- самим хочеться покодить, а колись;
- втрачається технічна кваліфікація, але помітити це колись;
- їх підвищили за вміння писати хороший код, а далі хороший код писати колись і не виходить. Починаються нерви «я повинен писати код, я не пишу код, я поганий працівник» і включається захист.
- ті, у кого є схильність до перфекціонізму, намагаються контролювати все. Мікроменеджмент вбиває.
у начальства слабкі навички донесення своєї думки: «ну там це, ну от, я хотів сказати про, зроби як я вже говорив»;
бюрократія. Приміром, обумовлено в контракті, що всі повинні працювати на сертифікованих ноутах через RDC — і все тут. Так, незручно, але за це платять гроші;
...

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

Менеджерам: одне із завдань лідера — це захист команди. Захист в тому числі і від начальства. Добре б вміти пояснювати, чим обґрунтовані ті чи інші начальницькі дії. І краще б використовувати не «вони ідіоти і вважають, що дев'ять жінок народять однієї дитини швидше, ніж одна», а «начальство бачить, що ми не встигаємо і хоче нам допомогти додаванням сильного співробітника».

«Я — ідіот», «мене ось-ось звільнять»

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

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

Відчуття «я тупий» — це нормально для синьйора. См. синдром самозванця і ефект Даннинга-Крюгера . Навпаки, якщо людина говорить: «я чудово знаю Java, JavaScript, C# і Ruby» або «я класно розбираюся в людях» — це напевно джуніор.
Звільняють IT нечасто, хоча мені довелося проходити цю процедуру неодноразово. Плюс-мінус надійний спосіб цього уникнути — це регулярно, раз на кілька місяців питати начальство: «як я працюю?» і «що я можу зробити краще для підвищення зарплати?».
Менеджерам: ваші співробітники точно час від часу відчувають себе ідіотами. У цей момент їм треба:
- спочатку дати підтримку: вислухати, нагадати попередні досягнення, ще раз вислухати. Про ланцюжок заперечення-гнів-торг-депресія-прийняття багато читали , втім, стадії можуть йти і в іншому порядку. Дати підтримку — це правильно, по-людськи і виправдане з бізнес-точки зору теж, адже людина повернеться в робочий стан;
- скористатися нагодою, і разом пошукати відповідь на питання «як таке запобігти надалі?». Як раз після епічних провалів найпростіше почати робити code review, ранні демки, синкапы, парне програмування та інші сложновнедряемые практики.

Зарплата: «мені переплачують» і «недоплачують»

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

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

Менеджерам:

слідкуйте за попаданням з/п працівників у загальний коридор:
- більшість схильна переоцінювати свою цінність на ринку праці. З іншого боку, зарплати ростуть, і сьогоднішнього вашого миддла запросто переманять на з/п синьйора;
- коли люди отримують оффер від іншої фірми на +20% зп, а потім контр-оффер від своєї +30%, то вони ображаються. Ну дійсно, раніше +10% отримати не виходило, а тепер відразу +30% пропонують?! Такий контр-оффер — це рішення на кілька місяців, та ще й коли стане відомо іншим співробітникам — їх сильно демотивує.
у будь-якій компанії приблизно половина співробітників дивиться на інші фірми. Що ви будете робити, якщо хтось із ключових піде? Погуглите про bus factor .

Хочу відкрити свою фірму

Дворазова різниця між вартістю години, яку виставляють замовнику і години зарплати — це більш-менш норма. Ця різниця оплачує відпустка, лікарняний, свята, залізо, офіс і т. д. І прибутку залишається умовних 10-15%. Тобто з 8-10 програмістів виходить прибуток у розмірі середньої зарплати. Детальніше можна почитати, наприклад, тут .

До моменту, коли у вас в штаті не буде 8 програмістів, прибутковіше отримувати зарплату. Це оптимістичний сценарій.

Звичайно, своя фірма або фріланс дають відчуття свободи, яке складно отримати, виконуючи вказівки начальства.

Менеджерам: тут важливо розділяти дві різні ситуації:

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

Вимагають оцінити терміни

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

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

постарайтеся таки допомогти менеджеру оцінити терміни. А якщо потім за зрив термінів він покарає — звільняйтеся нафіг.

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

обмежуйте вилку дуже приблизно. «Є шанс, що зробиш за день? Немає... А за два — вже є шанс?» і з іншого боку «Може це тривати до травня? Швидше? До середини квітня?»;
порівнюйте, об'єднуйте незалежні оцінки від різних людей;
використовуйте planning poker, метод футболок і т. д.;
розкажіть замовнику про NoEstimates :)

Замовник змінює вимоги

Іноді таке буває. Таке буває завжди. Потрібно пару раз побути в шкурі замовника, щоб зрозуміти — чому так.

На проекті з фіксованою ціною є дві крайності:

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

Що робити:

для fixed price — про будь-яких, навіть самих дрібних правки — повідомляти менеджеру чи хто там вів переговори про ціну;
для time & material — попереджати замовника про те, скільки це займе.

У Сергія Бережного був цікавий цикл на цю тему.

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

Чим ретельніше зроблено ТЗ, тим більше шансів, що воно вже застаріло і не потрібно.

Замовник ніфіга не розуміє в розробці

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

«Якщо Замовник хоче Чарівника, то він знаходить Казкаря» © менеджерська мудрість

Тут завжди змагання між бажанням дива у Замовника і вмінням пояснювати у Виконавця.

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

Доводиться допілівать чужий кривий код

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

зриви термінів;
маса помилок і недоробок.

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

Які плюси:

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

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

«Замовник тисне» і віддалена робота

Часто буває, що замовник тисне. І часто — це побічний ефект від віддаленої роботи.

Чому так?

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

Більш детально розповім на PMDay 1-го квітня.

Конфлікти

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

Неприємні завдання

Знаю класного бэкендера, який не любить Excel і сисадминство. Інший — не любить завдань по саппорт. Поки вони мовчать про свою нелюбов до якихось типів задач — менеджер зазвичай ніфіга не знає і не змінює.

Менеджерам: знайте, що люблять ваші співробітники, а що — ні :)

Естетика й гігієна інша

Чи можна на стіну вішати еротичний календар? А якщо порнографічний? Потрібно ходити в душ після тренування/велосипеда? Раз у скільки днів (тижнів) потрібно міняти футболку? Хлопцям — носити футболку-сітку? Дівчатам — цокати високими підборами і пшикаться могутніми духами? Включити кондиціонер або відкрити вікно? Є на робочому місці? А якщо апельсин (дуріан)?

Список можна продовжувати нескінченно, і ніякі корпоративні правила всі аспекти не вирішать. Кожен конкретний випадок треба домовлятися окремо і шукати якісь компроміси.

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

Менеджерам:

будуйте довірливі стосунки. Заздалегідь;
хоч трохи покопатися в мові жестів. Він простіше регэкспов.

Етика

З етичними проблемами ми айті стикаємося рідше. Хоча ось приклади:

мені довелося звільнити UI/UX в розпал кризи. Я знав, що у нього дружина ось-ось народить, але він відверто не вписувався в робочий процес;
що робити з людиною, яка на корпоративному принтері і корпоративної папері друкує з товстої художньої книги в тиждень? Чи міняється щось, якщо це інтерн на випробувальному терміні або, навпаки, мегаэксперт, яким фірма може подарувати принтер як бонус до зп? А готові відповідати на питання «чому йому можна, а мені не можна? А де це в правилах?»;
співробітник захоплюється стрітрейсингом, та інших підбиває. З одного боку — не моя справа, з іншого — вже кілька разів дрібні аварії потрапляв, і коли зіб'є когось всерйоз — питання часу;
співробітник дуже любить дівчат — раніше таких називали ловеласами, тепер модно слово «пікапер». Чи повинен я попереджати дівчат? Або вони дорослі люди і, якщо що, то розбитим серцем будуть страждати поза робочого часу? Або зробити навіювання хлопцеві?

Менеджерам: як би ви себе тут не повели — все одно будуть ображені. Лідери думок тут вирішують, важливо організувати їх діалог і не дати перейти на особистості. Ідіть за людьми, що мають авторитет у команді.

QA проти програмістів

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

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

Підлеглі

«Додали помічників, тепер зовсім ніколи працювати» — дуже приблизно: один підлеглий вимагає одну годину в день. Новачки і джуни вимагають час частіше, синьйори — більше, на обговорення серйозних питань.
Судячи з тут і тут , в український IT-басейн людей втікає 20% в рік, а витікає — 5%, і ми знаємо, що втікають джуниоры, а витікають синьйори, то що буде з рештою? Правильно, процентне співвідношення буде відхилятися у бік джунов. Хто буде з цими джунами возитися? Нинішні миддлы і синьйори. Ось така піраміда навчання.

Отримувати з джунов бізнес-користь — цінність цього вміння буде рости на нашому ринку праці.

Code Review

Не люблять у нас code review. Часто саме за некоректну зворотний зв'язок. Відчувайте різницю між варіантами «ти бовдур» — «ти поганий програміст» — «ти написав криво» — «це кривий код» — «тут краще зробити ось так» — «чи можна за допомогою лямбда-виразів скоротити цей код?». Багато синьйори люблять посамоутверждаться, і таки використовувати «ти-» формулювання з лівої частини списку.

Менеджерам: прочитайте, що таке конфліктогени і навчіться їх чути і швидко гасити. Вміння давати грамотну зворотний зв'язок теж згодиться.

Що вивчати?

Мов/фреймворків/бібліотек зараз дуже багато. А часу, чомусь, мало. Що ж вчити? А для чого?

Якщо для себе — то все одно що. Хоч фортран, хоч монади — лише б цікаво було.
Якщо для подальшої роботи або для працевлаштування — то краще щось з тих технологій, які зараз лізуть вгору. Кмк, це JavaScript і Python.
А якщо вже зовсім з точки зору прагматичної, то дивимося на ринок праці, наприклад, djinni .
- для джунов має критичне значення стаж. Ви наберете автоматично, і добре б до стажу додати ще і навички. Дуже добре.
- для синьоров технічні навички кваліфіковано за годину-другу не оціниш, і на перше місце виходить англійська. Дуже сумний для мене висновок, мені англійська дається з великими труднощами.

При навчанні темп роботи знижується. Якщо до цього весь час писав на Ruby, а тут вирішив nodejs освоїти, так на рубі сервак написати все одно швидше вийде. Коли дійдеш до такого ж рівня... Далі гуглити по «Крива процесу навчання (А. Бандура)».

Менеджерам: винні і депресивні вчитися не хочуть і не можуть. Так що якщо працівник хоче щось нове освоїти, то часто це ознака, що йому на роботі добре. Ну або він хоче щось вивчити і звільнитися, але тоді як ви про це дізналися?

Замість висновку

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

Опубліковано: 27/03/17 @ 10:00
Розділ Безпека

SEO Блог