75% соискателей на junior вакансию совершают эту ошибку

Три из четырех соискателей на нашу java junior вакансию теряют возможность попасть на второй этап собеседования из-за одной и той же ошибки при выполнении тестового задания.

 О чем речь?

Всем, кто прошел предварительный отбор hr'ом, выдается домой небольшая  задача для самостоятельного выполнения. В тексте которой есть следующий текст: 

<...>
Написать консольное приложение `TreeRender`: 
1. Приложение должно принимать на вход два параметра: `java --source 11 TreeRender.java INPUT_FILE_NAME OUTPUT_FILE_NAME`.
<...>
Ожидания от программы в порядке важности:
1. Работающая программа в соотвествие с ТЗ: на правильный ввод программа `TreeRender` выдает ожидаемый вывод (Проверка  работоспособности программы выполняется нами **автоматизировано**). 
<...> 

Правильность работы приложения и успешность выполнения задания проверяется автоматизировано скриптом. Большинство соискателей пишет приложение, которое не может пройти такую проверку. Причина - внешний интерфейс программы не соответствует тому, что ожидает автоматизированный тест. Т.е. внутренняя логика программы может работать безукоризненно, а автоматический тест не может вызвать программу.

Первая часть допускаемых ошибок имеет java-специфику:

• Класс называется, например, "MyApp", а не "TreeRender"
• Программа состоит из нескольких файлов или входит в пакет, например, *org.example*
• Приложение является gradle проектом, требующим зависимости от третьих сторон.  

Такие ошибки не позволяют выполнить java программу без дополнительных ручных действий.

К другой части относятся ошибки в семантике внешнего интерфейса, например,  программа не принимает аргументы, а запрашивает их в интерактивном режиме выводя в консоль  "Укажите аргумент INPUT_FILE_NAME:", что так же противоречит тексту ТЗ.   

Первая наша реакция была: "Ага, все ясно. Соискатель не способен читать и анализировать ДП. Если возьмем на работу кандидата, то потребуется осуществлять постоянный контроль и в конечном счете наим себя не оправдает". 

Но следом возникает вопрос. А может проблема в постановке задачи и мы тем самым отсекаем себя от хороших кандидатов? Возможно мы могли бы предоставить сервис автоматизированной проверки результата. Кандидат мог бы проверить программу на совместимость  требованиям до того, как отправит окончательный вариант. 

К нам приходит много резюме, однако у нас не достаточно ресурсов, что бы внимательно подойти к каждому кандидату . Отсев часто происходит по первичным критериям. Например, пустое голое резюме, где только имя, фамилия и вуз, обычно отправляется cразу в корзину. Такова правда жизни. На конкретную вакансию на собеседование можем позвать не больше 4-6 человек в неделю. С чистой совестью отказывали тем, кто не прошел автоматизированную проверку по любой из приведенных выше причин.   

13 лет назад я не прошел собеседование по схожей причине. Я получил задание:

Результатом выполнения задания является исполняемая программа, позволяющая ввести строку длиной не более 30 символов и осуществить ее проверку на корректность. Результат проверки должен выдаваться в виде одного из двух возможных сообщений - "Check passed" или "Check failed".

Я написал приложение, которое выдавало окно с сообщением, что то типа ShowMessage('Успешно'). Я не увидел или не придал особого значения словам "одного из двух возможных сообщений". Это была моя ошибка. `Face Palm`. Да, я конечно пытался придумать себе оправдание, что у меня не было опыта работы по четким ТЗ,  а скорее наоборот, был опыт отсутсвия четких ТЗ, требующий применять фантазию.

Я тогда сильно хотел получить оффер  на ту вакансию и пройти собеседование.  И именно этот провал многому меня научил: каждая деталь любого ТЗ важна.

Таким образом, внутреннее сомнение в правильности быстрого отказа по автоматизированному тесту не отпускало. Я начал искать знаки, которые бы подвердили или опровергли используемые подходы.  Код  приложений, которые проходили проверки автоматизировано, как правило, был лучше чем код приложений которые нельзя было проверить автоматизировано. А чтобы убедится в том, что  кандидаты прошедшие автоматизированную проверку сильнее, приглашали на собеседование и тех, кто такую проверку не прошел, несмотря на то, что внутри их приложений все равно был приятный код, который работал без ошибок в логике. Оказалось, что на собеседовании нет никакой корреляции между теми у кого программу можно вызвать как `java --source 11 TreeRender.java INPUT_FILE_NAME OUTPUT_FILE_NAME` и теми, у кого нельзя.  Вот такое открытие.  

Отмечу, что я знаю несколько хороших разработчиков и одного даже очень хорошего, у кого "пустые" резюме - как раз одна из тех причин почему резюме кандидата отправляется сразу в корзину. 

Какие выводы можно сделать ? Статью можно было бы назвать "75% нанимателей совершают эту ошибку, упуская хороших кандидатов". Но кандидату с этим ничего поделать нельзя. Процессы найма часто не совершенны. Спасение утопающего - дело самого утопающего. А такие относительно простые ошибки вольного тракатования ТЗ для кандидатов могут быть  болезненны. О них нужно знать и лучше не допускать.

Можно ли сэкономить набирая junior специалистов?

Дисклеймер №1: По стопам предыдущих двух статей "Эффективность по Skunk Works" и "У нас нет ресурсов для ревью кода"

Дисклеймер №2: Безусловно разделение на junior-middle-senior, используемое в статье, крайне условное и мало связано с опытом работы, а градация сильно зависит от компании, в которой дается оценка. Однако мы живем в реальности, в которой на hh в вакансиях ведущих it компаний используется такая терминология, и все мы, так или иначе, понимаем о чем речь, и примерно какой набор требований предъявляется в том или ином случае. И предвосхищая дальнейший текст статьи, заверяю, что абсолютные величины не так важны для сделанных выводов.

Мало кто хочет брать джуниор-разработчиков в трещащий по швам проект. Однако берут. И я заметил, что есть компании, в которых боятся брать сеньоров. Компания предпочтет взять нескольких джуниоров вместо одного сеньора. Мысль взять одного сеньора вместо мидлов или джуниоров, можно сказать, даже и не рассматривается.

Дисклеймер №3: Рассуждения по большему счету не про топ компании, в которых и так все в порядке, а скорее про остальное большинство. Так же разговор идет про технически сложные продукты, правда в возможность существования простых, в общем случае, особо и не верю. Простые продукты (вспоминая Пола Грэма и его книгу "Хакеры и Художники") вряд ли могут успешно существовать на конкурентном рынке, в противном случае их было бы слишком просто скопировать и повторить.

Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте.

В классическом варианте конечно же есть стремление сэкономить.
Джуниору можно мало платить. Их много на рынке, их легче взять.  Да, первые месяцы он будет бесполезен, но уже через несколько месяцев начнет приносить пользу, а через год отобьет все затраты. А еще можно сэкономить, или точнее мало потерять, если джуниор не прошел испытательный срок. Такая потеря не особо болезненна по сравнению с потерей более высокооплачиваемого специалиста. Один сеньор может распараллелить работу, нагрузив трех джуниров задачами не высокой сложности, беря на себя более высокоуровневые и сложные задачи. Тем самым сделаем продукт, а заплатим меньше, хотя может и не столь идеально и быстро. А еще беря джуниора на небольшую ЗП, мы не подрываем устоявшиеся зарплатные планки внутри компании.

Практически все доводы несостоятельны. Давайте по порядку.

## Себестоимость продукта с джунами выше чем с профессионалами

Платя зарплату джуниору, вы не платите за работу над продуктом, вы платите этакий базовый минимум, чтобы ему было на что существовать, ну и конечно за надежду, что когда-то и он полноценно встанет у станка. Дальнейший рост зарплаты от старта сильно не пропорционален росту эффективности. Т.е. себестоимость выполненной работы у малоквалифицированного сотрудника выше, чем у более квалифицированного. Поясним это. Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла - это две ЗП джуниора, а сеньора - 3 зарплаты джуниора.   Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов - 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности. 

 

 

 График построен на  моем опыте, но можно попробовать посмотреть на другие графики. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым.

 Фредерик Брукс, Пол Грэм, Дядя Боб считали, что высокопрофессиональные разработчики эффективнее остальных от пяти до десяти раз. Таким образом становится совсем очевидно, что каждый вложенный рубль в сеньора окупается гораздо быстрее, чем в джуниора.

"Мифический человеко-месяц":

>Руководители программистских проектов давно уже поняли, как значительны различия  в  производительности хороших и плохих программистов. Тем не менее результаты точных измерений  этой величины просто поражают. В одной из своих работ Сакмен,  Эриксон и Грант  измеряли  производительность группы  опытных программистов. Даже внутри этой группы отношение максимальной и  минимальной
производительности в среднем составило 10:1, а для  времени работы программы и затрат памяти - 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10  раз больше, чем у того, кто зарабатывает 10 тыс.  долларов. Обратное  также может быть  справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)

## Коммуникация - узкое место

Продолжая сравнивать 3 джуниоров против одного сеньора нельзя забывать и о том, что на коммуникацию и синхронизацию 3 джуниров уйдет порядка 10-20% общего времени. Чем больше людей, тем больше издержек. Таким образом, набор джуниоров идет и против стратегии  сохранения наименьшего количества разработчиков работающих над проектом. То, о чем говорил Келли Джонсон в Skunk Works, ну и конечно же Брукс.

## Джуниор - это инструмент, но не самодостаточная единица

Джуниор как правило совершенно не способен решать задачи высокой сложности. И есть иллюзия, что он может решать простые задачи. Да может, но если это задачи в вакууме. Но в рамках сложного продукта простота задачи может быть не столь очевидна.
Тут уже нужно виденье, которое есть только у сеньора. Моя практика говорит, что простых задач в сложных продуктах нет, есть лишь степень ответственности сеньора. Джуниор может не заметить, что "простая" задача на самом деле требует сложного решения, не увидеть потребности в рефакторинге. Зрение джуниора достаточно узко и не глубоко. И требует тщательного контроля, усиленного вникания старших товарищей в суть "простой" задачи, что бы не пропустить сложность. И как правило такое погружение и выполнение задачи по времени превышает время самостоятельного выполнения задачи сеньором.

На короткой дистанции джуниор может казаться эффективнее, чем он есть на самом деле, но только если не считать общую эффективность в долгую, учитывая что вернулось бумерангом.

## Подобное к подобному

Профессионалу интересно работать с профессионалами, они тянутся друг к другу. Синергия их качеств рождает верные решения. Работа в интересной команде с интересным продуктом может привлекать не меньше, чем высокая оплата труда.

Джуниорам нужны профессиональные разработчики чтобы расти. Но большое количество мидлов и джуниоров просто топят синьоров. Талантливые джуниоры вымываются в более интересные коллективы. В команде на долго зависают вечные джуниоры и мидлы. Профессиональные разработчики тоже теряют интерес и уходят, либо тупеют под количественным давлением не компетенции. При таких звоночках скорее всего и остальные взгляды на построение продукта расходятся со взглядами талантливых джунов, что еще больше подпитывает  их бегство в успешные компании. Дальше начинается замкнутый круг.

## Наем профессионала vs джуниора

Сеньора отчасти проще проверить. Он знает чего хочет, с ним можно говорить и не быть снисходительным на молодость, на то, что человек не обстрелянный. Его можно гораздо более точно оценить и не гадать на кофейной гуще, что же вылупится из яйца в итоге. За плечами есть проекты, которые можно обсудить и оценить, посмотреть код на гитхабе, провести сеанс парного программирования.
Возможно величина ошибки при неудачном найме профессионала выше, но вероятность ошибки гораздо ниже.

Наем джуниоров - это гораздо большая лотерея.  Какой процент джунов у вас выросли в сеньоры? Конечно же мы не рассматриваем явных талантов из хороших вузов, которые не светят в нашем случае.
Наличие блеска в глазах, психологической совместимости, способности писать алгоритмы и код почти всегда не является признаком, что из человека выйдет сеньор или даже добротный мидл. Сколько раз сталкивался с тем, что все этого присутствует, а способность решать задачи отсутствует.
По хорошему для эффективного найма требуется потоковая промывка джуниоров в поисках золотых песчинок на базе стажировки. Суммарные затраты на весь этот процесс на столько велики, что это не про маленькие или бедные компании.

## Джуниоры крадут время у наиболее боеспособных единиц

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

## Подводя итоги:  команда мечты

Получается что вообще сторониться джуниоров? Куда же им тогда податься?
Конечно же джуниоров можно брать, но на "сдачу". Наем джуниоров как стратегия на далекое будущее, в некотором роде рискованные инвестиции. По моему опыту на команду из 5 человек максимально допустимо иметь 1 джуниора и 1 мидла. И это не история про то, что джун и мидл это тестеры, devops'ы, техписы.


Допустим у нас на команду есть бюджет 550-600 т.р.
Можно пойти двумя путями и попытаться сформировать классическую команду из 7 человек, либо сделать упор на  максимальное количество профессиональных разработчиков.

Попытаемся представить как могла бы выглядеть первая команда:

### Команда строящаяся на основе джунов

Для каждого разработчика в списке ниже расставим крайне усредненную производительность на основе озвученного ранее.

1) Сеньор-лид - 150 т.р. (8х  - 4x (Половина времени на обучение и организацию)  = 4x)
2) Мидл? - 110 т.р. (5х - 1х Обучение = 4х)
3) Мидл? - 80 т.р. (2x)
4) Мидл? - 65 т.р. (1x)
5) Мидл? - 60 т.р. (1x)
6) Джун - 55 т.р. (0.2)
7) Джун - 50 т.р (0)

Общая производительность без учета потерь на коммуникацию: 12.2x
Принято считать, что добавление каждого нового члена в команду отъедает до 5% общего времени на коммуникацию. Т.о. общая производительность с учетом потерь на коммуникацию: 12.2x * 0.7 = 8.54x
КПД: 66 т.р. за 1x производительности.

Проблемы этого варианта, кроме низкого КПД:

* Сложность уменьшения текучки кадров. Много сотрудников находятся на этапе быстрого роста ЗП. Уровень ЗП должен соответствовать навыкам и рынку, а это бывает сложно синхронизировать. Проще уйти в другую компанию с повышением ЗП. Ко всему прочему, можно допустить, что такое стремление сократить издержки на людей негативно отразится и на ЗП ведущих разработчиков, заставив их чаще посматривать на сторону.
* Сложность удержания бюджета. Зарплаты у джуниоров на начальных этапах растут опережая инфляцию и производительность. 

### Команды на основе сеньоров

1) Сеньор-лид - 170 (8x - 2x (Орг. деятельность) = 6х)
2) Сеньор - 160 (8x)
3) Сеньор - 160 (6x)
4) Мидл - 100 (3x)

Общая производительность без учета потерь на коммуникацию: 23x
Общая производительность с учетом потерь на коммуникацию:23x * 0.8 = 18.4x

КПД: 32 т.р. за 1x производительности.

Дополнительные плюсы, кроме высокого КПД:

* Большой запас по КПД дает возможность увеличения ЗП для удержания сотрудников, прежде чем команда станет не эффективна по сравнению с командой на джуниорах
* Продукт качественнее (быстрее, эффективнее, юзабельнее, проще)

## Выводы

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

Эффективность по Skunk Works

 Прочитал "Skunk Works. Личные мемуары моей работы в Локхид"

Очень занятная книга об одном из самых секретных КБ времен холодной войны по ту сторону океана. Много рассуждений о модели взаимодействия государства с частными производителями, бюрократии, политики в технической сфере, профсоюзах, материально-технических аспектов в наукоемких секретных производствах. Все очень интересно, но зацепило другое.

История SkunkWorks в первую очередь взрывает своей эффективностью. Принципы работы которыми делится Бен Ричи (глава SkunkWork в 70-80х) не являются откровением как минимум со времен "Мифического человеко-месяца". Однако книга на столько яркая, что заставляет еще раз оглянуться на разработку в которой участвуешь и задуматься о том, куда уходит время, так ли нужны нам эти митинги, таски, отчеты, код ревью, планирования, ретроспективы для создания продукта. Что если просто выбросить хотя бы половину из этого миллиона ритуалов? 

SkunkWorks - маленькое секретное подразделение Локхид, которое могло строить прорывные проекты с безумно высокой эффективностью. U2 полетел за 8 месяцев, SR-71 Blackbird - самолет способный в 62 году продолжительное время летать на 3 Max разработала команда из 75 инженеров-проектировщиков, программа прототипа F-117A от идеи до первого полета за каких то 30 млн. $  и 2 года.

Как команда из меньше чем 100 инженеров могла создавать проекты оставившие такой существенный след в истории? Сравните их со списком фич последней мажорной версии вашего продукта.  

Успех SkunkWorks много кто хотел повторить, однако никто не готов был принять методику и поверить в людей.

Бен Ричи говорит, что они не были избалованы комфортом. У них не было отдельных кабинетов, массажных кресел, офис менеджеров, этажных хозяюшек. Столы стояли впритык, люди сидели буквально в полуметре друг от друга.

Но у них было другое:

• Повернутость на минимизации всей лишней деятельности.
• Устранение преград для коммуникаций (от слесаря до инженера-проектировщика расстояние броска камня, от специалисты до специалиста расстояние вытянутой руки)
• Высокопрофессиональный коллектив, лучшие из лучших.
• Высокая мотивация и сплоченность коллектива, несмотря на мало комфортные условия работы. Что являлось мотивом для профессионалов? Работа в коллективе профессионалов, интересная работа, результат. Одно тянет другое.
• Максимальный уровень свободы, минимальный уровень бюрократизма
• Открытая среда - "Мы поощряли наших людей работать творчески, импровизировать и пытаться использовать нетрадиционные подходы к решению проблем и не мешали им."
• "Мы стремились достичь эксплуатационной надёжности Шевроле, а не совершенства Мерседеса. За 20% усилий достичь 80% результата. Имей бы мы тогда сегодняшние мощные компьютеры, это бы ускорило проектирование и упростило бы испытания, но совершенство редко было целью Skunk Works. Если мы ошибались в расчётах на полкилограмма или на градус, это не сильно беспокоило нас."
• Если надо нарушить правила - значит надо нарушить. Это не было проблемой при должном уровне компетенции, которая впрочем падала по мере роста.
• "Всеобщее управление качеством". За контроль качества ответственны все причастные к процессу создания изделия.
• "Уникальные материалы или детали должны избегаться,  везде где возможно. Уже готовые детали должны использоваться даже в ущерб лишнему весу"
• В начале дешевый прототип.  

 
Кто то увидит здесь отголоски Agile, XP, Lean. Да! Все старо как мир. А еще история близки в том, что Agile тоже мало у кого работает.

Одно время, Бена Ричи сманивал Нортроп. И вот, что ответил Бену Келли:

“Чёрт возьми, Бен, я не верю ни одному слову, которое этот парень тебе сказал. Я поставлю своё ранчо на то, что Нортроп не создадут свой собственный Skunk Works. Компания даёт пустые обещания, потому что видит, насколько успешны мы. На самом деле менеджеры не верят в идею независимых подразделений, где из-за секретности они не могут точно знать, что происходит внутри. Не обманывай себя, у нас в менеджменте тоже есть люди, которых возмущаю я и наша независимость. Люди из аэрокосмической промышленности, даже уважающие нашу работу, хорошо знают, что чем меньше людей работает над проектом, тем меньше дохода можно получить от крупного правительственного контракта и возрастающих издержек. Сохранение небольшого количества людей снижает возможности для повышений. Чёрт, на главном заводе они дают повышение за большее количество людей, находящимся под руководством; я даю повышение тем, кто контролирует меньше людей. Это означает, что такие люди делают больше и принимают на себя больше ответственности. Но большинство руководителей думает совершенно другим образом. Руководство Нортроп ничем не отличается от всех остальных в этом бизнесе: все они пытаются построить империю, потому что именно так их учили делать. Эти парни - сплошь эксперты в прикрывании своих задниц путём выноса решений на голосование. Они никогда не согласятся создать подразделение, которое абсолютно не будет в них нуждаться. Они играют в игру под названием “Контроль”, и если Skunk Works действительно работает, как надо, то контроль это именно то, что они не получат."

Если вы не умеете готовить, то единственный путь получить хороший борщ - соблюдать рецепт до запятой. Незначительные отклонения могут погубить все дело. В современном IT есть множество проверенных рецептов на многие случаи жизни. Но на словах у всех Agile и скрам и прочие другие слова. На поверку много оговорок и очередной локальный исторически сложившийся подход с "элементами из agile" в рамках красной корпоративной культуры.

"Любая компания, чьё положение зависит от разработки новых технологий, должна иметь в своём составе Skunk Works; сейчас существует примерно пятьдесят пять подобных подразделений в различных отраслях промышленности – это не очень много. Но если в Локхид Skunk Works был чрезвычайно успешен, почему сотни других компаний не попытались сделать тоже самое? Одна из причин, по-моему, заключается в том, что большинство других компаний не понимают концепцию, задачи и ограничения, в то время как многие другие не хотят предоставлять свободу и независимость, которые являются необходимыми компонентами для успешного функционирования предприятия типа Skunk Works."

Самый важный процесс

Если бы меня сейчас спросили, какой самый важный процесс в компании, то ответил бы: работающий процесс. Но работающий процесс это курица или яйцо? Тогда мой ответ ретроспектива - достаточная отправная точка для работающего процесса. Что у вас? Скрам, аджайл, канбан, тестирование, какая модель зрелости, чем там сертифицированы - ни как не подходит под  термин "самый важный процесс".
Есть ли у вас работающая ретроспектива, работает ли обратня связь, есть ли лифт-матка для процессов? В конечном итоге вопрос обратной связи главный в теории автоматического управления и динамических системах.

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

"У нас нет ресурсов для ревью кода" (с)

Последнее время часто слышу "у нас нет ресурсов на ревью кода" или "Нет времени вводить ревью сейчас, у нас много багов, надо их править. Вот появится время, тогда будем заниматься методологиями".  Данные выражения я ставлю в один ряд с "Нам не нужен гит, у нас одна ветка". Где же причина, а где следствие? 

Попалась отличная вводная статья про управление качеством продукта https://vsavkin.livejournal.com/6050.html. Без воды,  где все снято как с языка.
Если в кратце, тезисно по ней:

К прописным истинам можно отнести:

1. Качество процесса разработки определяет качество разрабатываемого продукта!
2. Чем позднее дефект обнаружен, тем дороже стоит его исправление
3. «повышение качества системы снижает расходы на её разработку».
   Думаю этот пункту можно добавить несколько примечаний, но в общем случае согласен.
    

Что особо отметил для себя:

1. Только на тестирование нельзя полагаться не только потому, что это позднее выявление дефектов, но и потому что большинство видов тестирования имеет низкий КПД.
2. Формальная инспекция кода эффективный инструмент (наш выбор это использование в ревью кода/дизайна практик формальной инспекции).

Интересную статистику подтверждающию Макконела по поводу сравнения эффективности инструментов можно найти в слайдах  автора. Средняя стоимость поиска и исправления дефекта:

1. Инспекция - 9 чел-часов
2. Интеграционное тестирование -  21 чел-часов
3. Системное тестирование - 34 чел-часов

А так же для мнемоники притча http://losev-al.blogspot.com/2013/12/kpi.html#

Интересно, для кого-то все еще существует проблема "курицы и яйца" применительно к дилемме: в компании выстроена методология и культура, потому что компания успешная и богатая, или все же компания богатая и успешная благодаря выстроенной методологии и культуре?

Список из рекордов на коленке

Честно подсмотрено.

THeader = record
  x,y,z: TMyRecordField;
  NextLabel: packed record end;
end;

На сколько прекрасно, на столько и отвратительно. Но восхищает однозначно хотя бы тем, что это вообще работает. Если что, то NextLabel это ссылка на следующию записью.