Меня зовут Лариса. Я работаю в Google и веду блог на larrr.com, где я изначально и опубликовала эту статью.
Сегодня я предлагаю вашему вниманию статью, которая изначально была написана исключительно для внутреннего пользования Google. Мне очень понравилась, так что я связалась с автором, с ее разрешения я ее немного переделала, и получила разрешение от Google Press на публикацию. Перевод мой.
На всякий случай – это не официальный Google документ, и Google не несет ответственности за его содержание. Он субъективный, и написан сотрудником для сотрудников.
Советы для инженеров
15 апреля 2013
Отредактировано 21 мая 2014
Переведено 31 августа 2015
Gretta Bartels, Software Engineering Manager at Google
Уважаемый читатель,
В этом документе я описала некоторые принципы, на которые я опираюсь в работе со своими командами. В них нет ничего принципиально нового или революционного, все эти принципы давно известны каждому из нас. Но знать и делать – это две разные вещи. Поэтому этот документ также является напоминанием и для меня самой о том, что моя работа менеджера заключается том числе и в том, чтобы самой следовать этим принципам, и напоминать о них другим.
Один из моих более опытных коллег научил меня тому, что для менеджера очень важно быть предельно предсказуемым. У менеджера должен быть какой-то набор простых правил, о которых знают все его подчиненные, и которым они могут следовать даже когда менеджера рядом нет. Поэтому моя цель – чтобы программисты в моей команде могли задать сами себе вопрос “Что бы на это сказала мой менеджер?”, и сами себе на него правильно ответить. Тогда команда сможет работать практически самостоятельно, без моего руководства. А я буду сидеть дома и кушать пирожные :).
Вот список моих основных правил:
1. Занимайтесь той работой, которая действительно важна
1a) Всегда задавайте себе вопрос “Почему мы это делаем?”
Что бы вы не делали, все всегда должны четко знать две вещи – 1) почему вы это делаете? 2) как вы поймете, что достигли нужного результата? Даже если вам кажется, что вы можете ответить себе за вопрос “почему?”, не останавливайтесь на первом подходящем ответе, смотрите глубже. Задавайте себе этот вопрос снова и снова, пока ответ не будет простым, очевидным и одновременно с этим довольно масштабным.
Это чем-то похоже на метод “5 почему”, когда техних несколько раз задает себе вопрос “почему?”, углубляясь в ответ чтобы найти причину неполадки. Но в нашем случае я предлагаю использовать этот метод для любой работы, а не только для нахождения причин проблем.
А вот вам и пример из жизни. Одна из моих команд сейчас работает над улучшением качества данных для Google Maps (а именно – находим и устраняем внутренние противоречия в данных). В это случае “почему”-цепочка может выглядеть примерно так:
Мы устраняем противоречия в данных
-> для того, чтобы мы могли проще и быстрее интегрировать существующие и новые данные
-> для того, чтобы мы могли обновлять данные быстрее
-> для того, чтобы Google Maps были максимально точными
-> для того, чтобы качество Google Maps соотвествовало очень высокому стандарту и требованиям пользователей
-> для того, чтобы люди активно пользовались и доверяли Google Maps (и продуктам Google в целом)
Выглядит довольно просто, не так ли? Но исходя из моего опыта, далеко не все инженеры задают себе эти вопросы и видят дальше конктретной и обособленной задачи над которой они работают.
На самом деле понимать “почему?” для своей работы очень важно. Кричитески важно, я бы сказала.
- Без этого понимания намного сложнее оценивать результаты своих трудов. И намного сложнее адаптироваться к постоянно меняющимся требованиям проекта, в результате которых вам может потребоваться доказывать менеджменту что то, что вы делаете, действительно важно.
- К тому же, так вы сможете найти других людей и команды, которые преследуют ту же самую фундаментальную цель. Вы сможете найти поддержку и союзников, важность которых очень сложно переоценить.
- Плюс, вы сможете лучше приоритизировать уже имеющиеся проекты.
Кстати, ответов на ваши “почему?” может быть несколько. Это хороший знак – вероятно, ваш проект действительно важен.
И еще важное, особенно для менеджеров: используя “почему”-цепочку, вы не только сможете лучше понять зачем вы что-то делаете и как делать это лучше, но и увидеть другие стратегические области развития для ваших проектов. Просто пройдите с другого конца цепочки и задайте себе вопрос “как?”.
1b) Самое важное – это результат
Как менеджер, я оцениваю своих сотрудников по следующим параметрам: Знания и Опыт, Сложность, Лидерство и Результаты. Хоть и все они важны для профессионального развития и карьерного роста, один из параметров значительно важнее прочих. Это – Результат.
Большинство компаний – это не обучающе-развивающие площадки для программистов. Это – бизнесы, которые работают, и именно благодаря этому в них можем работать мы. Кстати, лично мне это сочетание – бизнес и технология – очень нравится. Мне нравится работать над вещами, которые изменяют мир. И многим инженерам с которыми я общалась на эту тему – тоже.
Любопытно, что Результат вовсе не следует из остальных параметров. Можно быть умным, опытным, знающим свое дело харизматичным менеджером или техлидом команды, которая работает над невероятно сложной и интересной задачей. Задачей, которая не имеет вообще никакого стратегически важного значения. С другой стороны, вряд ли возможно создать что-то стоящее не обладая знаниями, или не будучи хорошим руководителем.
Кстати, насчет сложности. Бывает, что для достижения важного результата не надо делать ничего сложного. Это нормально. Всегда ищите и берите простые и одновременно важные проекты, когда вам предоставится такая возможность.
1c) Планы бесполезны, но важны
Я верю в OKR (сокр. Objectives and Key Results — цели и ключевые результаты — метод, используемый в современном менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль за реализацией поставленных задач. Wiki.). Я прошу всех инженеров в своих командах писать и оценивать их ежеквартально.
У письменной постановки целей есть много преимуществ. Но я думаю, что самая важная вот эта: ваше время ограничено, и вы должны занять его вещами, которые принесут больше всего пользы. К тому же они позволяют существенно улучшить качество планиромания. Без стратегического планирования вы легко можете попасть в две очень распространенные ловушки: переоценить то, сколько вы можете сделать за квартал, и утонуть в срочных делах вместо важных. Впрочем, с планированием вы тоже можете в них попасть, но вам будет намного проще их распознать и из них выбраться.
Ситуация, когда вы занимаетесь срочными вещами вместо того, чтобы заниматься важными, знакома многим. Вот в этой статье эта тема неплохо раскрыта. Почитайте, если вам интересно.
Еще более интересная проблема – это переоценка своих возможностей. Как менеджеру, мне регулярно приходится помогать инженерам быть более аккуратными в своих оценках – по моему опыту очень многие сильно переоценивают количество работы, которую они могут сделать за данный промежуток времени. Бывали случаи, когда люди ставили много целей, делали каждую на 30-50%, но не довели ни одной цели до запланированного результата. Намного лучше бы было сделать две или три цели на 100%.
Используя письменное планирование и оценивая свои результаты по прошествии квартала, многие могут существенно улучшить свои навыки постановки и достижения целей. Даже существенно не изменяя свою продуктивность, они начинают делать более реалистичные прогнозы и доводят несколько действительно важных вещей до конца. Именно поэтому я считаю OKR невероятно важными для своих команд, и надеюсь что как можно больше людей освоит этот навык.
2. Не теряйте время даром
2a) Ускоряйтесь (aka Как насчет парочки тестов?)
Во время моей учебы в университете, в качестве зачетной работы мне надо было написать игру Boggle с красивым интерфейсом и поддержкой для удаленной игры нескольких пользователей. Естественно, я даже пальцем не шевельнула до последнего дня перед сдачей. В 3 часа ночи я обнаружила что моя наскоро написанная программа содержит баг, который вылезал под самый конец игры.
Так что остаток ночи я провела играя в свою игру, пытаясь повторить баг и найти его причину. Конечно же, это было как минимум глупо. Мне просто надо было установить таймер игры на 5 секунд и дело пошло бы намного быстрее. В свое оправдание я хочу сказать, что дело было под утро, мне очень хотелось спать, а не искать ошибки в моей программе. Еще лучше было бы написать тест, но тогда я про тесты даже не слышала.
Каждый раз, когда вы повторяете какой-то кусок программы снова и снова, пытаясь найти ошибку и исправить ее, сделайте все, чтобы эти повторы были максимально короткими. Скорее всего это покажется вам лишним, так как вы будете уверены, что нашли ошибку с первого раза. Но так бывает очень редко. Вероятно, скоро вы поймете, что это не оно, и вам придется повторить процесс сначала. И потом еще раз.
Поэтому при работе над любым проектом постарайтесь сделать так, чтобы он максимально просто тестировался. Сделайте его модульным, сделайте так, чтобы любую часть программы можно было максимально просто изолировать и протестировать. Поверьте, настанет момент, когда вы будете рады, что сделали это. И если у вас возникнут проблемы с модульностью и изоляцией, то это хороший повод задуматься о том, насколько хорош ваш дизайн в принципе.
Похожий принцип применим и к работе с людьми и продуктами. Когда вы находитесь в ситуации неопределенности, подумайте о том, как провести быстрый и простой эксперимент, который бы дал вам хоть какие-нибудь предварительные данные.
2b) Избавьтесь от проблемы раз и навсегда (aka Автоматизируйте)
Люди не должны тратить время на вещи, которые намного лучше получаются у компьютеров. Это даже не обсуждается.
Мы все занимаемся программированием, чтобы сделать жизнь проще и автоматизировать то, что можно автоматизировать. Казалось бы, инженеры будут пытаться максимально применить этот принцип к себе в том числе. Но оказывается, что вовсе нет!
Много раз я видела людей, из раза в раз делающих одну и ту же повторяющуюся задачу вручную вместо того, чтобы ее автоматизировать. Главное оправдание в такой ситуации – “это займет всего несколько минут, а автоматизация процесса займет целый день”. Иногда это даже правда, но далеко не так часто, как может показаться.
Автоматизируя задачу:
- Любой сможет справиться с этой задачей, даже человек, который только начал работать в команде, или автоматический процесс. Минуты ручной работы быстро соберутся в часы и даже дни – задача будет запускаться когда вы спите, когда вы едите, и когда вы болеете.
Автоматизирование маленькой задачи может открыть двери для более масштабной оптимизации. - Вы можете обнаружить ситуации, о которых вы даже не задумывались до того, как попытались автоматизировать весь процесс.
- Создавая процессы для того, чтобы позднее их автоматизировать, вы существенно улучшите свой навык дизайна процессов.
2c) Развивайтесь
Не занимайтесь одним и тем же слишком долго. После того, как вы освоили какую-то область, либо автоматизируйте ее (см. выше), либо обучите другого инженера для этой работы и двигайтесь дальше. Растите профессионально, не позволяйте себя застояться.
Иногда люди не делают этого потому, что их работа кажется им рутинной и они не хотят переваливать эту рутину на других. Но то, что вам может показаться рутиной, будет прекрасной возможностью чему-то научиться для другого, возможно менее опытного, инженера. Даже если это не так, для команды скорее всего имеет намного больший смысл, когда в конкретной задаче разбираются сразу несколько человек. Иначе она может стать узким звеном.
Иногда люди держатся за свои задачи потому, что им кажется, что объяснить их другим слишком сложно, или потому, что они считают, что справляются с ними лучше всех. Если это ваш случай, то вам стоит всерьез задуматься о создании хорошей документации.
Я постоянно советую инженерам в своих командах переключатся на новые задачи и развиваться профессионально.
3. Не работайте в вакууме (aka Общайтесь с другими)
Старайтесь описывать дизайн систем, над которыми вы будете работать, заранее (aka пишите design docs). Посылайте эти документы вашим коллегам и спрашивайте, что они думают. Делая это, вы:
- Упорядочите ваш собственный мыслительный процесс.
- Удостоверитесь, что похожим проектом не занимается кто-то еще.
- Улучшите свой дизайн, воспользовавшись полезными советами ваших коллег.
- Намного проще найдете коллег, которые согласятся вам помочь.
- Покажете себя активным и ответственным членом команды.
Говорите о своей работе (можно со слайдами). Предлагайте другим рассказать об их работе. Активно интересуйтесь, чем занимаются другие в вашей и соседних командах. Вы и ваша команда от этого только выиграет.
Многие не хотят говорить и писать о своей работе пока она не готова. Или они просто не любят писать. Это слабоватые оправдания. Если вы не хотите писать, или не хотите делать презентацию сразу для целой команды, то начните с малого – просто поговорите с одним конкретным коллегой, нарисуйте схематичный дизайн на доске. Это поможет вам упорядочить свои мысли, и написать документ или обсудить его с целой группой будет намного проще.
Если статья вам понравилась, то заходите ко мне в блог. Возможно, там вы найдете для себя еще больше интересного. У меня уже почти 300 статей на тему Google, карьеры, саморазвития и продуктивности (некоторые из них когда-то были на Хабре). Я люблю писать, и, как мне кажется, у меня неплохо получается. Как минимум иногда.
Буду рада, если вам понравится!
Комментарии (57)
Scf
06.06.2017 08:21+13Вот и гугль уже захватили эффективные менеджеры. Меньше экспериментов и инноваций, больше работы на результат.
tzlom
06.06.2017 08:41+5Хоть с тезисом «захватили эффективные менеджеры» я в целом согласен, с тем, что «больше работы на результат» это плохо я категорически не согласен, те же гугл карты и принцип парето — 20% усилий делает их картами, 80% — офигенными картами, но эти 80% скучны до умопомрачения.
Когда гугл выкидывает сервисы просто потому что «мы должны разрабатывать продукты для всех, а не для узкой группы» или потому что они недостаточно прибыльны — это «эффективный менеджмент» и игра с цифирками на бумаге. Когда же он пинает своих сотрудников чтобы они доводили продукты до конца — это настоящий эффективный менеджмент (и замечу что со стороны гугла это сомнительное вложение средств, сравните подход гугла и огрызка к картам, тут недавно была статья показывающая какие люди делают для себя а какие для галочки).
mazahakajay
06.06.2017 11:04Не совсем соглашусь по поводу яблокарт. Похоже, что яблоки их вообще не делают, а просто закупают полностью у ТОМТОМ`а и просто накладывают свои цвета. А «корпорация добра» действительно пилит сама.
igordata
09.06.2017 00:06Не уверен точно про яблокарты, но чуть ли ни все карты мира происходят из here.com, которой с 2007 по 2015 владела внезапно Nokia, а сейчас — неожиданно Intel.
https://en.wikipedia.org/wiki/Here_(company)
LonelyCruiser
06.06.2017 09:33+10Сделайте его модульным, сделайте так, чтобы любую часть программы можно было максимально просто изолировать и протестировать. Поверьте, настанет момент…
Доброе утро кэп.
lxsmkv
07.06.2017 03:03кэп-то кэп, однако по сей день, к сожалению, случается, что тестируемость не закладывается в архитектуру системы. И видимо до сих пор понимание такой необходимости не просочилось во все мозги.
hamMElion
06.06.2017 11:08+6Иногда люди держатся за свои задачи потому, что им кажется, что объяснить их другим слишком сложно, или потому, что они считают, что справляются с ними лучше всех. Если это ваш случай, то вам стоит всерьез задуматься о создании хорошей документации.
Ахаха! Кажется, автор статьи забыла задать свои 5 почему в этом случае. Как правило, люди держатся за свои задачи, потому что если кто-то другой сможет справляться быстрее (автоматизация) или дешевле (документация) или просто кто-то ещё сможет понять как это работает (стандартизация), то люди становятся заменимы и могут потерять работу. Заменимость кадров — один из основных конфликтов между работодателем и работником. И вот в этом автору статьи надо бы хорошенько разобраться за очередной пироженкой :)
SirEdvin
06.06.2017 16:21+6Подсумировав всю статью можно одной фразой "Программисты — решайте менеджерские задачи!".
Занимайтесь той работой, которая действительно важна
Я так и вижу программиста, который сам решает какую ему задачу делать, а какую — нет и плевать он хотел на желания кастомера. Или он их должен угадывать? Для таких задач есть или BA, или есть продуктовая компания — Product Owner, который и занимается приоритизацией.
Не теряйте время даром
Почти все программисты любят автоматизацию. Камнем предкновения опять становится менеджер и бизнес, который утрясает бюджет и за которым закрепляается решение по тому, нужна ли автоматизация или просто доплатил джуну.
Не работайте в вакууме
Фигак-фигак и в аджайл. Опять же, программисты в целом не против писать документацию, но на проекте нужна для этого коза и выделенное для этого время. Это опять же проблема CTO и менеджера.
Причем тут программисты?)
SirEdvin
06.06.2017 16:43А вот совет перечитывать коммит сообщение после коммита мне бы не помешал :(
JekaMas
07.06.2017 08:40Все стало достаточно понятно с автором после слов о вере в OKR, которые суть надстройка над KPI…
Scf
07.06.2017 08:56OKR мне напомнило классическую «соковыжималку», когда программистам дают работы на треть больше, чем они могут сделать.
JekaMas
07.06.2017 11:00+1Конечно же нельзя забывать, что для эффективной работы программистов надо еще указать им, чтобы 20% работы они придумали себе сами, как дополнительно… стимулирующую.
OKR — это совсем не KPI, говорят манагеры. При KPI палку в зад закручивают против часовой, а тут — по часовой. Совсем другие… впечатления.
sergeyns
06.06.2017 17:34+5Смешно. Менеджер пишет инженерам «занимайтесь тем, что действительно важно». Вообще-то инженеры занимаются тем, что им скажет начальство, эти самые менеджеры…
aml
06.06.2017 23:53По-разному бывает. Менеджер не всегда микроменеждит команду и за руку показывает, какой класс написать или какой метод порефакторить. На высоком уровне, конечно, менеджер говорит, над каким продуктом и какой фичей работать. А на низком уровне этим занимается сам программист, и надо уметь самому себе дать по рукам и остановиться, если работа пошла не в ту сторону.
utoplenick
06.06.2017 17:34+4Люблю такие тексты: «Я не знаю как у вас все работает, и вообще не шарю во всем этом, но сейчас дам вам пару ценных советов от капитана Очевидность»))
barantaran
06.06.2017 17:34+2Интересно, сколько поисковых запросов от инженеров вида «советы менеджер».
combat34
06.06.2017 17:35+31. Почему есть такая профессия как Менеджер?
2. Почему Менеджер отвлекает (или дёргает без повода)?
3. Почему Менеджер ничего не понимает в разработке?
4. Почему Менеджер хочет что бы все ускорялись?
5. Почему существует хренова гора систем управления проектами для менеджеров написанные разработчиками.
Гора советов для разработчиков! И ни одного для менеджера!
Ребята разработчики, нужно срочно написать советы для менеджера!
1. Перед тем как взять проект — подумай 7 раз, 1 раз возьми.
2. Не бери по нескольку проектов за раз.
3. Обсуждай с командами проекты.
4. Мотивируй команду не пустыми обещаниями.
5. И наконец сами ускоряйтесь(попробуйте сгонять за кофе для всей команды в 5 раз быстрее обычного)
P.S. В старые древние времена в древнем Риме на галерах солдаты подгоняли рабов грести вёслами быстрее. Вот тут такая же картина. А потом эти рабы развились и сделали этим менеджерам двигатели.
1b) Самое важное – это результат
— за результатом кроется истина.
Простой пример — Великая Китайская стена.
Представляю если бы эти советы писали управляющие(менеджеры) того времени.
dklein
06.06.2017 17:35+5Это какая-то эпическая банальщина в стиле мотивароских и менеджерско-лайфхакерских статей, которые обычно принято считать инфо-шумом. На мой взгляд, спасти эту статью могли только конкретные детальные примеры.
very-smarthome
06.06.2017 17:35+11b) Самое важное – это результат
В конечном счете Ваш результат — это Ваша смерть. Поэтому самое важное не результат, а процесс. Ибо процесс — есть жизнь.
igolkin
06.06.2017 18:24Сомнительно. Каждый должен разбираться в своей сфере. Как менеджер может давать совет программистам, если только сам не имел опыта подобной работы?
aml
06.06.2017 23:58В гугле менеджеры нескольких уровней иерархии вплоть до директоров — технари. Они или выросли из инженеров, или были инженерами в прошлом. И уж точно они все прошли точно те же самые инженерные интервью, что и программисты. Так что они могут давать советы, да.
Справедливости ради, в статье много умолчаний, которые истинны для Гугла, но могут отличаться в других компаниях.
otvorot2008
06.06.2017 19:16+1Большинство компаний – это не обучающе-развивающие площадки для программистов. Это – бизнесы, которые работают, и именно благодаря этому в них можем работать мы. Кстати, лично мне это сочетание – бизнес и технология – очень нравится. Мне нравится работать над вещами, которые изменяют мир. И многим инженерам с которыми я общалась на эту тему – тоже.
Как раз это и плохо, в том же Google, 20% времени компания выделяла на развитие своих сотрудников. Неужели все изменилось даже там? Т.е компания не заинтересована в развитии сотрудников, а только в зарабатывании денег? Человеческий капитал — самый ценный как никак.
Старайтесь описывать дизайн систем, над которыми вы будете работать, заранее (aka пишите design docs)
Описан какой-то водопад, в нашем то современном экстремально-итеративном мире. Системы зачастую проектируется итерациями, а не за один вечер. У Макконела это хорошо описано. Проработанный дизайн системы с нуля — редкость, и не присущ большинству современных процессов разработки.
Всегда ищите и берите простые и одновременно важные проекты, когда вам предоставится такая возможность.
Это из разряда — Android-приложение для заказа пиццы? Что-то на уровне дешевых советов о том, как поднять свой стартап.
Это – Результат
Мне сразу вспомнился лемминг-вождь из Мадагаскара, отчитывающих своих подчиненных ;)
Говорите о своей работе (можно со слайдами)
Зачем мне рассказывать каждому (!) о том, что я делаю каждый день. Для этого есть issue tracking и логгирование времени. Если речь идет про донесение каких-то своих идей людям в компании, то для это вовсе не нужны слайды — пустая трата времени, достаточно доски и маркера. Если вы не можете донести свои мысли и идеи без слайдов, значит плохо их формулируете. Давний принцип педагогики кстати — если не можешь донести сложные вещи простыми словами до первоклассника, значит ты "плохой" педагог :)
SirEdvin
07.06.2017 13:57Как раз это и плохо, в том же Google, 20% времени компания выделяла на развитие своих сотрудников. Неужели все изменилось даже там? Т.е компания не заинтересована в развитии сотрудников, а только в зарабатывании денег? Человеческий капитал — самый ценный как никак.
https://geektimes.ru/post/190362/
Да, пришло время эффективных менеджеров, которые зарабатывают деньги, а не делают продукты.
Isma
06.06.2017 20:21+2Наверное не «почему», а «зачем». Вы же о целях писали. «Почему» — «по какой причине», «зачем» — «с какой целью». Разница огромна. Только это очень неоднозначный путь. Бывали случаи, когда «эффективные менеджеры» нанимали «эффективных тренеров», которые давали навык команде как правильно задавать вопрос «зачем» и выстраивать цепочки из них. А потом увольнялось 80 процентов команды потому что конечный ответ оказывался очень неприятным — «незачем». Для того, чтобы очередной «эффективный менеджер» почесал свое ЧСВ.
DnV
06.06.2017 20:43+2«В универе я писала программы за день и теперь буду делиться своим опытом скоростной разработки»?
kk86
06.06.2017 20:50+1Планы бесполезны, но важны
Что бы это значило? Это шутка такая?
Да, планы как правило не выполняются. Это совсем не значит, что они бесполезны. Максимум, план может иметь ограниченную полезность для конкретного применения (равно как и любой другой инструмент).
План это модель прогресса проекта.
All models are wrong but some are useful — George E. P. Box
"Количество полезности" плана, риски (стоимость) игнориования/фиксации плана, и многое другое определяют степень его важности.
lxsmkv
07.06.2017 02:52Планы бесполезны, но важны
это неудачно перефразированая цитата Д.Д. Эйзенхауэра:
Plans are worthless, but planning is everything
kk86
07.06.2017 05:00Это ее перефразирование, поскольку утрачен исходный смысл. Я вижу большую разницу между "планы бесполезны, но важны" и "планы ничего не стоят, но планирование это всё".
Так или иначе, моя мысль была о том, что планы ценны даже если и не соблюдаются и на 50%. Спасибо, что дали подсказку про первоисточник.
DarkTiger
07.06.2017 00:47+3Эти пункты кажутся банальными, но за каждым из них стоит ободранная шкура, уж поверьте.
Мой любимый вопрос к инженерам: что тебе надо прямо сейчас?
И если ответ «Отпуск», то элементарное чувство заботы о собственной заднице заставляет срочно пойти общаться с заказчиком и попытаться перенести сроки фичи, которую пилит инженер.
Но, к счастью, это случается не так часто. Обычно запросы бывают легкими: «Оперативки добавить», «Монитор поменять», «Пнуть заказчика, чтобы уточнил, наконец, пункт ТЗ», «Помощника на рутинные задачи» — в общем, все то, что относительно легко выбивается извне.
Самое приятное в таком подходе — узнаешь о внешней проблеме сразу: инженеры знают, что я все равно спрошу и дам требуемое со всей возможной скоростью, если можно, так чего тянуть-то?
Вот только такое возможно лишь в крупных компаниях, с мелкими такое не проходит.
Все просто. Менеджер никогда не должен забывать, что он — по большому счету, не более чем паразит, который паразитирует на человеческих слабостях разработчиков и заказчиков: неумение договариваться, неумение выделять главное, неумение общаться с руководством и коллегами — и все такое прочее. Этот паразит должен жить в симбиозе с экосистемой «разработчики-заказчики-руководство-коллеги», делая полезные действия и создавая полезные для экосистемы артефакты. Иногда об этом забывают, увы, и менеджер становится бесполезным паразитом.dklein
07.06.2017 08:54Это понятно, что эти истины из практики, но, согласитесь, преподносить их нужно как-то по-другому, а то смотрится в стиле «статья о том, как быть успешным и счастливым», если абстрагироваться от IT-тематики :) «Никого не слушайте! Идите за своей целью! Не тратьте время на ненужные вещи».
DarkTiger
07.06.2017 13:51Вообще-то все важные вещи очевидны. Я вот сыну сейчас пытаюсь обьяснить фразу «Посеешь привычку — пожнешь характер» и знаете, не очень-то и получается…
А что Вы хотели в статье прочитать? Ну висит у меня на рабочем месте заламинированная памятка «В 14 часов в понедельник актуализируй список рисков по проекту» и такой мудрости — полный лист формата А4. Я в него и не смотрю даже.
Менеджер работает в своем стиле, и этот стиль индивидуален. Помню, я своего первого подчиненного, студента-второкурсника, 14 раз заставлял переделывать его первый результат. Сейчас удивляюсь, как он меня с четвертого раза на фиг не послал. Но этот-то парень за следующую пару лет вырос до ведущего инженера (к защите диплома — неплохо так), и славился полным отсутствием косяков. Вот и пойми теперь, прав я был или нет… Сейчас, конечно, так делать однозначно не стал бы :)
razielvamp
07.06.2017 03:18Всегда, когда читаю статьи по теории управления, маркетингу или прочим подобным лженаукам (сарказм), то создается такое впечатление, примерно, как шефповар рассказввает как мыть огурцы: "я заметил, что в некоторых домах люди начинают резать огурцы неподготовленными для пищеварительных процессов, это пораждает кучу сопутствующих проблем. Чтобы исправить ситуацию прощего всего воспользоваться присособлением-краном, который должен находиться неподалеку от вас. Обычно такой процесс называется EWVTC (effective wash vegetables trough cran). Для удобства и комфорта процесса я бы посоветовал вам крутить сразу два винтиля с красным и синим маркерами. Многие люди недооценивают масштабы процесса на этом этапе и используют лишь вентиль с синим маркером. Да вы можете выполнить это с одним огурцом, но что если у вас целая корзина овощей? Ваши руки просто замерзнут и вы не сможете ввполнить процесс эффективно и в сроки. Это скажется на вашем результате..."
Хотя, ради справедливости добавлю, что иногда, читая такие статьи, действительно узнаешь как вытащить наружу что-то, что воспринимаешь на подсознательном уровне. Ибо подсознательное здраво оценивать и оптимизировать практически нереально.
lxsmkv
07.06.2017 03:28Я постоянно советую инженерам в своих командах переключатся на новые задачи и развиваться профессионально.
Вот как-то я себе не могу представить как это в жизни происходит. У тебя спектр задач, например в моем случае автоматизация тестирования. Мой тимлид не против если я буду помогать в разработке, но это я могу делать только в том случае, если основная работа от этого не будет страдать.Так? Никто не скажет мне, «Алексей, харе уже тесты писать, засиделся совсем, лица нет, давай развейся, попрограммируй на яве, а тесты за тебя ..» вот в том-то и дело что твою основную работу за тебя никто делать не будет. Ротация задач, не уверен что работает. Я не смогу сходу писать/чинить приложение как это делает опытный разработчик, а разработчик не сможет писать/чинить тесты с той же эффективностью как это делаю я. Все в силу набранного опыта. Так что все эти предложения о смене спектра задач, ни к чему не приводят. Хотя на словах очень красиво, каждый мог бы каждого подменить. И какое-то лукавство в этом есть. Зачем мне чтобы меня кто-то мог подменить, да? Job Safety Index нужно держать на уровне. И даже понимая, что JSI — глупость в широком плане, но такое поведение — часть человеческой природы. И самый ярый альтруист не станет делать что-то во вред себе. И каждый боится, что с дополнительным навыком на него лягут и дополнительные задачи/обязанности. Гарантий-то никто не дает. Поэтому все готовы друг другу помогать, но никто не хочет мерять на себя чужой хомут. Такое вот равновесие Нэша.DarkTiger
12.06.2017 00:48Моя любимая фишка при уходе в отпуск — назначить на мое место исполняющего обязанности РМа кого-нибудь из команды. Убиваю двух зайцев — во-первых, инженеры видят, на какой горячей сковородке я сижу, во-вторых, начальство видит, на какую горячую сковородку сядут они, если решатся меня сменить. Представьте себе сами — внезапно посадить инженера в РМ-ское кресло на пару недель :) А я спокойно в отпуске читаю копии писем перед сном, тут главное — от смеха на себя ничего не пролить. Иногда приходится вмешиваться, но это если совсем край, например, заказчик начинает рычать.
Ну а если человеку захотелось вдруг сменить область и попрограммировать на джаве — велкам, плавно вывести инженера из команды — это ни разу не то же самое, что искать замену на стороне, высунув язык. Поиск и подготовка замены инженера в этом случае, говоря цинично, становится головняком самого инженера.
Поймите простую вещь: если программеру приличного класса осточертела его работа — все, конец, его уже в проекте нет. Это свершившийся факт. Повышение зарплаты лишь оттянет уход на 3-4 месяца, не больше. Все, что менеджер может в данной ситуации — вовремя заметить это состояние и начать спокойно готовить замену. Не заметит в запарке или постесняется спросить — сам себе буратиноlxsmkv
12.06.2017 01:23ну так и получается что меня ценят потому что больше эту работу делать некому. Нехочется и неумеется. Я на перекурах коллег подкалываю, когда они мне начинают жаловаться на свои проблемы: «давай меняться ты будешь писать тесты, а я ..» — «не-не-не, давай не будем..». Даже джуны которые по началу просто стонут от сложности системы, не хотят попробовать автоматизацию. Хотя само программирование в автоматизации проще, но нужно дофига держать в голове и постоянные расспросы, выяснение, что да как в системе поменялось.
Мне кажется просто есть люди которые хотят работать nine-to-five и те, кто работают ради успеха проекта. Есть люди которые когда нет задач сидят и валяют дурака, а другие проявляют инициативу. И это не от позиции зависит, а от человека. У меня колеги спрашивают, зачем я читаю дома рабочую почту. Я им объясняю, мол если мы в пятницу сломали билд перед уходом с работы, можно его починить до девяти утра понедельника, это сэкономит один день (у нас ежедневные билды) — они не понимают, зачем такие лишения. Так же быть в курсе, что тебя ждет на работе перед началом работы, позволяет расставить приоритеты заранее, и тратить меньше времени на «разгон». К сожалению автоматизация хоть и является желанием заказчика, но мой ПМ сказал, что это хоть и важная работа, но не первостепенная. Оно понятно, первостепенен продукт, он приносит деньги. И тут выделить собственную незаменимость трудно. Ведь в принципе никто не незаменим. Поэтому я просто делаю объем рассчитаный на троих человек.
И мне кажется, что уважение коллектива ко мне за последние пол года выросло в разы. Раньше ко мне отностились типа " ты кто? ты тестировщик, вот и иди нафиг, тестировщик" (ну в шутку конечно), а теперь прислушиваются, сами приходят за советом. Осталось это как-то в денежный эквивалент перевести :)
xPomaHx
07.06.2017 10:43Слышал что такое только у русских, но не могу воспринимать такие советы нормально, хотя я трудолюбивый и работаю на результат, но чувство что меня эксплуатируют сильнее. Есть ведь отлаженная система, чем лучше и больше работаешь тем больше ЗП, если строить обратную зависимость и за те же деньги заставить больше работать возникает конфликт.
SirEdvin
07.06.2017 14:00Слышал что такое только у русских, но не могу воспринимать такие советы нормально, хотя я трудолюбивый и работаю на результат, но чувство что меня эксплуатируют сильнее.
Это есть у всех. Просто это приглушаеться корпоративной политикой и имиджом компании.
DarkTiger
12.06.2017 00:55Читал и сам убеждался в простой эмпирической зависимости: если в одной компании зарплаты инженеров различаются в 2 раза, то производительность различается в 10 раз. Почему, собственно, сеньору и рады в любой компании.
Конечно, это если не включать в статистику людей, принятых по блату :)
JDTamerlan
15.06.2017 13:52Спасибо Вам, Лариса, — отличная статья! Да и на блоге вообще красиво пишите! :-)
corr256
Именно это ключевое в работе менеджмента… Вы тут работайте, а я пока полежу на пляжу.
TheKnight
Это предложение не о том. Оно о отлаженных процессах.
khett
К сожалению, статья как раз про то что «я не хочу делать процессы, оценивать результаты, управлять приоритетами, ставить задачи, руководить отделом, вы там сами как-нибудь разберитесь, а я потом приду и накажу кого захочу» ))
avost
Руководить — это вовсе не значит бегать с дикими глазами и мешать команде спокойно выполнять работу. К сожалению, многие горе-манагеры этого не понимают. "здесь мерилом работы считают усталость" (ц)
khett
причет тут дикие глаза и сваливание на сотрудников обязанностей менеджера? Разработчики нужны чтобы разрабатывать продукт в рамках спецификаций. И это их работа и они это умеют делать лучше всего. А раздумывания в стиле «а какой смысл в этой фиче?», «почему именно она нужна заказчикам?», «а хорошо ли я работал этот квартал» — только мешают этому процессу. Более того, они ломают всю идею с управлением разработкой, когда разработчики начинают проявлять инициативу в неожиданных местах. Это хорошо, если сроки «резиновый» и на бюджет наплевать. Но когда мы работаем на тот-же «Fix Price» или даже «T&M», когда необходимо защищать бюджет и показывать результаты, то восторгов от заказчика может не оказаться.
Поэтому все эти советы — очередные костыли, когда менеджеры просто не знают как организовать работу своих сотрудников, и заставляют их самих «эксперементировать» на себе.
avost
Видите ли в чём дело. Если я не знаю "какой смысл в этой фиче", я её сделаю так, как мне покажется нужным её сделать, а поскольку в вашей схеме разработчикам насрать на продукт, то фича будет в рамках спецификации, но абсолютно не тем, чего хотел заказчик. И 99% сделают ровно так же. Не по злому умыслу, а потому что в этих условиях и невозможно сделать иначе. 1% да, случайно попадёт в цель. Вот и бегают такие манагеры-идиотики все в мыле и запарке, пытаясь "организовать" работу стохастического механизма, который сами и поддерживают в стохастическом режиме. Ну, да, зато они всегда "в работе", что можно продемонстрировать вышестоящему начальству!
khett
Хм… Если в Вашем варианте вселенной разработчики разбираются в предметной области лучше специалистов, то я Вам искренне и по доброму завидую. В моей же суровой действительности человек не может знать все сразу и обладать экспертными знаниями в произвольных областях. Поэтому разработчки не может принимать решения, какими проводками отражать ту, или иную операцию, или какие параметры с какими весами должны использоваться в скоринге, а тем более о том, как должны себя вести исполнительные устройства в различных режимах полета самолета или движения автомобиля.
Если разработчику что-то непонятно, то вместо выдумыния чегото на ровном месте, он просто идет к тому. кто ему ставит задачи (будь то архитектор, системный аналитик, продукт менеджер или даже черт лысый) и задает вопросы ему. А его (разработчика) линейный руководитель должен обеспечить, чтобы впредь подобная информация в нужном объеме была согласована и присутствовала в соответсвующих документах (спецификации, ТЗ, PRD и т.д.).
З.Ы. А вот почему у вас менеджеры носятся по офису в мыле и запарке — это уже вопрос к Вам. Вы их наверно дустом душите? ))
avost
Лучше менеджеров? Скорее всего, да.
А кто может в вашем варианте вселенной? Неужели их менеджер? Мы ведь про работу менеджера толкуем.
Почему непонятно? Как правило, понятно. Только не так, как должно быть :). В этом и проблема.
Теоретически, вполне возможен сферический программист в вакууме, способный написать, к примеру, бухгалтерскую систему исключительно по тз ничего не понимая в бухучёте, но на практике хотел бы я посмотреть на этот цирк с конями.
Почему ко мне? Это у вас претензии к тем руководителям, которые настолько отладили процессы, что могут уже и не бегать за каждым чихом. А у меня задачи ставятся в очень сильно общем виде — сделай так, чтобы было хорошо ;). Дальше я делаю хорошо, поскольку поколупался в предметной области, а менеджер менеджерит не меня, а занимается теми делами, которые мне не интересны. Но, да, здесь не поточно-конвейерное производство.
khett
Мы толкуем про работу менеджера задачей которого является обеспечение сотрудников всей необходимой информацией, в том числе. В данном случае, задачей менеджера является найти этих специалистов и добиться, чтобы они довели до разработчиков что и как должно быть реализовано. А не перекладывать эту работу на исполнителей.
Это и есть непонятно. И это проблема менеджера, что аналитики прошляпили возможность многоякой интерпретации задачи.и вопрос принятия решений переместился на самый низ.
На приктике мы имеем модули в которые вносят исправления десятки человек, и через несколько лет никто не способен сказать, что там, как и почему. Так что уже пусть будет лучше «цирк с конями», чем сотня спутавшихся и сросшихся от времени осминогов, из которых надо сделать «трепетную лань»
Ну то есть в итоге в предметной области разбирается не каждый разработчик, а некий «аналитик», что и противоречит статье. Но если Вы ожидаете. что простой программист легко разберется в тензорном исчислении, в гидродинамике, расчете усталостных изменений некой двутавровой балки, или даже в области финансового планирования, то я хочу в эту вселенную все сильнее )
Да, к адептам «идеальных процессов на все времена» я не принадлежу и задача менежера, в том числе, и состоит в том, чтобы корректировать процессы по мере необходимости.
avost
В моей вселенной, разумеется, инженеры разбираются в предмете лучше продакт-менеджеров.
Я, кажется, понял. В вашей реальности разработчики — это нанятые по объявлению за еду бродяги? Не. Я про инженеров. Инженер — это, вообще говоря, лицо, способное к принятию решений по предмету, входящему в его область компетенции.
Как-то так и получается, когда решения принимают менеджеры. Я, давайте, повторю вопрос — вы в самом деле уверены, что можно написать бухгалтерскую систему силами "разработчиков" ничего не смыслящих в бухучёте?
Даже если в предполагаемой системе есть некий "аналитик", то это ведь не менеджер?
Я не знаю что вы понимаете под словом "простой программист". Если выпускника ПТУ, то да.
Ну, в моей вселенной "программист" — это, как правило, инженер с высшим математическим или, в крайнем случае, техническим образованием. Да, в принципе, ему нет проблем в этом разобраться.
А вот каким образом вы сможете озадачить вашего ПТУшника реализовать и отладить решение гидродинамической задачи без погружения в предмет, хотел бы я посмотреть. "Вот цифры на входе, на выходе должны быть вот эти цифры?" Это как в той байке:
int rnd() { return 4; / это воистину случайное число — я бросал кости / } :)
khett
Отличная формулировка. Так вот, областью компетенции Инженера является разработка ПО. А не конструирование водометных установок, например. Не так ли?
Давайте. Не будем далеко ходить, возьмем «1С». Вы доверите разработчику платформы (именно платформы, а не конфигураций, даже с учетом того, что там значительный объем кода от майкрософт) сводить баланс Вашей организации? Или формировать для нее учетную политику? Это обычные задачи главбуха, кстати.
Я где-то предлагал менеджеру ставить задачи программисту? Мое замечание относилось к предложению некоего менеджера, чтобы сами разработчики себе ставили и/или уточняли задачи.
Причем тут «ПТУшник». Альтернативно одаренных с дипломами МФТИ есть, причем в товарных количествах. Кроме того, я не слышал ни об одном «инженере-программисте» который бы сделал систему, помогающую в анализе данных с геолокатора, хотя лично знаю геолога, писавшего таковую. Или сколько «инженеров-программистов» руководят хирургическими отделениями? При том, что лично сталкивался с практикующим хирургом, который на Objective-C пишет системки, помогающие ему в этой работе.
Вообще, складывается ощущение, что либо мы по разному понимаем термин «разбирается», либо просто занимаемся «мерянием» того самого органа. Высшее образование разработчику позволяет понять формализованную задачу. С этим никто не спорит. Но я не встречал ни одного разработчика, который бы разбирался в сложной предметной области на одном уровне со специалистами, не потратив на это хотя-бы пары лет. И вот таких «пары лет» обычно нету, чтобы разработчик пресловутой системы для расчета гидродинамиских задач потратил на изучение
той же турбулентности или кавитации и в итоге реализовал систему. которая сама находит профили поверхностей для заданных условий.
avost
Ну, лично у меня и нет никакого продакт-менеджера. А когда такое было, это был посредник к заказчику. Ну, чтобы инженеры с заказчиками не сильно часто общались.
Не так, конечно. Если эти инженеры разрабатывают ПО для конструирования водомётных установок, то их областью компетенции является разработка ПО в области конструирования водомётных установок. А вот сможет ли разработчик платформы 1с из вашего последующего примера, писать по водомётов, это вопрос на засыпку. Сможет ли ваш продакт-менеджер поставить водомётную задачу 1с-нику, который ни в зуб ногой в тензорах и гидродинамике?
Ну, да, предлагали. Вот здесь:
«я не хочу делать процессы, оценивать результаты, управлять приоритетами, ставить задачи,… "
Ну, вы же сами написали, что ваши программисты не обязаны разбираться в тензорном исчислении, гидродинамике и всём прочем. Только писать код для данных в режиме чёрного ящика. Для этого высшего образования не требуется. Справится и птушник. Ну, а если вы используете инженеров в режиме птушников, значит вам деньги девать некуда.
Ну, я работал как-то в нефтяном проектном институте. Один инженер-программист в отделе писал динамическое моделирование нефтедобычи, а другой процесса наклонного бурения, что ли. На основе данных сейсморазведки и локаторов, что ли — не знаю как правильно — тех радиоактивных (или не радиоактивных) штук, которые опускают в скважину, а они в процессе опускания чего-то излучают и регистрируют отклик. А руководил отделом радиофизик. Извините, если что-то описал неправильно, это 15 лет назад было.
Руководство хирургическим отделением ни как не получится соотнести с инженерной деятельностью даже если удастся натянуть сову на глобус.
Наверное, "системки", которые из сырых данных мрт сканирования собирают вот те самые красивые 3д картиночки человеков в разрезе? :) тогда ваш знакомый — гений! Поздравляю вас, вам сильно повезло, что вы знакомы с таким человеком.
Почему сводить баланс? Это тоже из области совы на глобусе. Это не его дело. А вот написать программы, соотносящие конкретные бизнес-процессы с конфигурацией платформы — разумеется.
И главбух программирует их на 1с? Хммм.
То, что у вас нет достаточно времени, это ваши проблемы, а вот каким образом разрабатывать и отлаживать систему решения гидромеханических задач, не разбираясь в гидромеханике (тому же 1с-нику), мне по-прежнему интересно было бы узнать. Я, как-то пытался во времена оны реализовать какой-то хитрый способ решения систем жёстких дифференциальных уравнений по формальному описанию, ничего в этом на тот момент не понимая… Такая хрень получилась! :)
alsii
Есть такая замечателная штука: математика. Если мы ей пользуемся, у нас мгновенно исчезают мотоциклисты, догоняющие велосипедистов; бассейны с трубами, из которых выливается вода; землекопы, копающие траншеи и дети, которые едят конфеты. Вместо этого у нам появляются переменные и уравнения. Которые мы можем замечательно решать вообще не представляя, о чем они. Более обще это называется "абстрагирование" и "декомпозиция". только так и решаются достаточно большие задачи.
Так и в программировании. Если разрабатываемая система достаточно велика, то у нас никто вообще не знает полностью, как она работает. Каждый работает на своем уровне абстракциии решает свою, достаточно узкую задачу. При этом те уровни абстракции, которые предполагают знакомство с предметной областью, в больших проектах находятся достаточно далеко от программиста.
avost
Йеп! И гидромеханика, как ни странно, является одним из её разделов. :)
А теперь отмотайте — мой оппонент, вроде бы, утверждал, что программисту, который пишет программы для гидромеханики не обязательно разбираться в этой самой гидромеханике. При этом, правда, он же говорил, что не видел таких программистов, а нужную программу написал как раз специалист по гидромеханике.
Вообще-то, нет. Ну, кроме таблицы умножения, конечно.
Не могли бы вы озвучить область вашей деятельности, чтобы не связаться случайно с системой о которой разработчики не знают как она работает. А, уже увидел — вебсайты. Да, есть такие вебсайты о которых никто не знает как они работают. Но там другая проблема — слово "работают" к ним, обычно, малоприменимо. :)
Это у вас простые проекты. Возможно, большие, но простые.
khett
А почему не разработка водометных установок? Или все же компетенции разработчиков ПО недостаточно чтобы быть экспертами в данной предметной области (в разработке водометных установок)? Как ни странно, но сможет. Если в системе будет встроенный язык, то разработчик интерпретатора вполне будет компетентен в этом. То же самое касается отображение схем и данных. Вот насчет мат.аппарата – тут другой вопрос. Необходим будет разработчик, который сможет понимать постановку задачи от инженера-расчетчика.
Вы прекрасно поняли, что «ставить задачи» в данном контексте относилось к тому, что брать в работу из бэклога/пула/списка заданий. Менеджер не говорит что конкретно и как должно быть реализовано в рамках продукта. Поэтому Ваше передергивание не уместно.
И снова Вы передергиваете. Я говорил, что разработчики не являются экспертами в предметных областях. И поэтому не могут принимать решения что конкретно реализовывать, а что нет, и если реализовывать, то в каких рамках. Мат. подготовки разработчиков достаточно, чтобы понять логику того, что делает. Все остальное лежит на совести экспертов/аналитиков/архитекторов. И да, программисты не обязаны иметь знания на уровне профессоров математики, или разработчиков-гидродинамщиков. Ваши инсинуации про «черный ящик» остаются на Вашей совести.
И что это должно опровергнуть? Задачи ставит специалист, а разработчики ее (задачу) реализуют.
Вообщето автоматизация административных и бизнес-процессов является вполне себе инженерной задачей. И, согласно Вашим утверждения, инженер-программист обязан отлично знать предметную область, на уровне эксперта. Или все-же не обязан? Хотя есть туча всякого ПО для автоматизации процессов в клиниках.
Он конечно гений, но ему нужны хотя бы программки для рутинных, повседневных задач типа ведения графика дежурств, расписания операций, контроля за эффективностью деятельности сотрудников. Как видите, ничего сложного. Но в существующих системах нет того, что нужно именно ему.
То есть Вы подтверждаете, что программист не в состоянии свести баланс предприятия и/или найти ошибки в нем? То есть программист не является экспертом в области бух.учета? Ч.Т.Д. Будь разработчики (да и постановщики задач) экспертами, то не было бы тучи 1Сников чуть не каждой конторе с количество сотрудников от 50 человек.
Нет, главбух говорит что и как разработчики должны делать.
Этим занимается математик и инженер-расчетчик. Программист лишь реализует то, что скажут специалисты. И без минимальной мат.подготовки (которая и дается в ВУЗе) он их просто не поймет.
Что снова подтверждает мою позицию – программисты не являются экспертами в предметных областях. По крайней мере, если у них нет непрерывного и постоянного опыта работы в оных.
Извиняюсь что вмешиваюсь, но мои краткие комменты
Гидромеханика является частью физики, а не математики.
Если не выдумывать, а внимательно слушать и читать оппонента, то наконец услышите, что я утверждал и утверждаю, что программисты не являются экспертами в предметных областях и не могут принимать решения о том, что и в каких объемах должно быть сделано. Надеюсь теперь Вы наконец поймете о чем и что именно я говорил.
К сожалению, дискуссия потеряла смысл в виду передергиваний и выдумок оппонента.
aml
Это должно быть и целью менеджеров — наладить процессы так, чтобы они работали и не требовали вмешательства самих менеджеров, и программистов — сделать системы так, чтобы они работали и не требовали вмешательства людей. «Кушать пирожные» — это метафора. Для работы всегда есть непаханное поле.