2 новини про паріматч на головній — схоже первним авторам занесли. Це єдина компанія зі всього санційного списку про яку є окремі новини на ДОУ наразі.

Это бред. Нельзя просто так вернуть компании даже 100 долларов — это ведь зачисление на счет компании. Компания должна оказать физ лицу услугу или передать товар. Кроме того это облагаемая налогом прибыль. Короче я к чему — в таких ситуациях ошибка просто высчитывается из следующей зп, а кто успеет уволится — ну спишут эти деньги на безвозвратные потери. Любой бизнес с тысячей и более сотрудников, ежемесячно терпит миллионные потери (в гривнах) по разным причинам. Не выполненные контракты, штрафы, разнообразные пени, риски резкой смены курса гривны и т.п.

Так — справа у вартості години роботи ))
Крім того не завжди програмісти можуть взагалі написати зрозуміло документацію.
На проекті було 2 тестувальники — як я бачу у статті, наврядче там є техрайтер.

Чи не забагато відповідальность напрограміста?
— знати всю систему (щоб розуміти впливи при розробці своєї фічі)
— знати свою МП
— знати як працює рушій БД на проекті
— враховувати безпекові ризики при написанні коду
— часто — бути фуллстеком
— красномовно і швидко писати документацію
— знати (часто додаткову) МП для написання автотестів
— при цьому встигати писати якісний код у стиснуті терміни!
— я так розумію реліз менеджмент теж на хлопцях
— може ще скарги їм почати приймати від людей і відповідати, щоб менше часу минало від виявлення бага до його фіксу?

Звичайно замовнику це дуже зручнно — по сіти на тебе працюють 3 фріланери на яких повна відповідальність за все: від деталізації усної постановки задачі двома речення від замовника — до забезпечення якості, релізу і документуваня.

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

«После релиза обычно всплывало много багов, клиенты жаловались.»
— Это вообще как? Зачем вы вообще релизились с багами?
Если их не находили на этапе тестировани — надо просто менять тестировщиков.
Если фича была плохо документирована и вылазило то, чего не тестировали — писать доки и, верочтно, все равноменять тестировщиков.

«Обычно на этапе тестирования вылезало большое количество ошибок и мы не успевали их фиксить вовремя.»
— Значит надо менять инженеров. Почему они так плохо проектировали фичи?
На проекте вообще была дока?
Вы понимаете что программист 90%времени думает и проектируе, 9% читает код и только 1% кодит?

«При этом бывало, что у Олега Рогинского, нашего фаундера, через несколько дней после планирования релиза уже был назначен customer call, на котором он должен был презентовать новую фичу.»
— Вот вам лайфхак. Один раз задержите выпуск одной фичи и после этого показываете ее уже готовую чрезе неделю в то время делаете фичи Б, В, Г ...
— Кроме того это опять же проблема или отсутствия документации (зхнания инженерами системы) или отсутствие платирования при выполнении задач.

Ребята — вы просто запретили инженерам косячить! «Типа я вроде сделал, а тестировщики пусть проверяют».

Есть такое понятие в Scrum как Definition of Done. Можно ввечти такое правило что, задача отдается в тестирование только если разработчик видит, что она рабоатет по документации на тестовом окружении.
Можно не давать премию, если любая задача вернулась к разработчику более 3х раз (для начала) в джите это отлично видно. И потом снижать порог.

«Но у нас были инженеры, которые хорошо знакомы с таким подходом и умели это делать. И вот они показывали пример, менторили тех, кто учился.»
— Ну то есь инженеры которые не косячат были.

«Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA»
— Значит это плохой QA, не зря есть анекдот

Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар
и заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
—1 кружку пива,
qwertyuip кружек пива.
’ or 1 == 1 кружек пива.

Ну та а регрессия?
Хотя бы в связанных модулях.
Рефакторинг как раз требует регрессии.

Внутренние программы тоже можно тестировать.
Как правило всегда есть долг по приведению документации в соответствие проекту.
Если тестировщики толковые они могут писать или оптимизировать автотесты.

Штирлиц никогда не был так близок к провалу как в этом комментарии)))

Але якщо компанія маленька — то аутсорс знімає залежність від одного єдиного співробітника, який не має права по суті ані хворіти, ані піти у відпустку.
Звичайно якщо аутсорсити 10, чи навіть 30 співробітників, тим більше однієї професії то це питання — чи вигідно?

Почитав дискуссію у коментарях.

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

1. Керівництво хоче знати чи переплачують вони співробітникам і наскільки.
2. Співробітники хочуть розуміть чи буде у них премія та річна надбавка і як їх отримати.
3. Рекрутери хочуть бачити чи схильний співробітних піти з продуктової компанії.

Наприклад ось швидкі відповіді («у звичайномупроекті роблять так ...»):
1. Замовити чи купити дослідження ринку праці по місту / країні. (навіть на ДОУ є просте опитування, щоб зорієнтуватись)
2. Сформулвати 1-3 пріорітети (фічі, інтергаціх) на рік для кожного співробітника. І мініум поточних задач розв’язаних на місяць.
3. Спостерігати на мітінгах чи за обідом, що людина не подає ідей, критикіє чужі, веде себе деструктивно.

Тепер можемо порівняти ці дві системи і приймати рішення про впровадження:
а) наскільки більш точна інформация від запроповованої системи?
б) наскільки ця точність критична — я якісне покращення знанні про ринок і колектив, а також задоволенності співробітників прозорісстю КПІ?
в) скільки часу (грошей) треба для підтримання цієї системи у рамках організації?

На якому періоді часу проведено експеримент? (Хоча б рік минув)
Скільки часу зайняло впровадження? (Інталяція, тюнінг параметрів, навчання користувачів)

Ну і класичні проблема будь яких КПІ:
— що міряємо — те люди і нарощують, причому дуже творчо :) з мініумом зусиль
— якщо показників стає забагато, то люди припиняють паритися взагали. Занадто складно цілеспрямовано впливати на премію/підвищення

Вони навіть Minecraft зіпсували )

По факту стаття вийшла про проблеми найму сіньорів.

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

Але кори приходить ПМ/HR і питає які технології використовуютсья на проекті (навіть окремо у бекенді чи фронтенді) — він отримує свій фантастичний список :)

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

Я розраховував на публічну відповідь. За контакт дякую.

У статті ви пишите, що британці мали клопіт з тим, що корпус не можна використовувати у коменційних цілях. У вас, на гіті, теж ліцензія, яка передбачає тільки некоменрійне використання. Що мені робити, якщо мені потрібні тексти для створення ігри зі словами? Чи можу я використовувати github.com/brown-uk/corpus

И случайно ВР рассмотрена свой вариант закона об амнистии первым (сначала все должны разойтись) первы и тут же приняла его.

:) «как бы старая, для Вашего, не подняла»
А вообще — кто будет колоть дойную корову? Чтоб иммигрировали?
Хоть кто-то платит налоги, наши 5% сравнимы с 46% от многих белых ЗП.
+ Эти день тратятся в Украине: на машины, квартиры, электронику, чуть более дорогую еду, одежду в том числе ребёнку, ты можешь себе позволить ездить в IMAX и ходить вечером в ресторан с девушкой/женой, покупать новые игрушки ребёнку (а не просить у соседей).
Ок — мы можем тратить 2-3 тысячи долларов в месяц не в Украине. Читал вроде программистов тысяч 40.