Outsourcing stories

Недавно вспоминал очень хорошую книгу об управлении: «Сначала надо нарушить все правила: что лучшие в мире менеджеры делают по-другому?» (First, Break All the Rules: What the World’s Greatest Managers Do Differently):

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

1. Знаю ли я, что от меня ожидается на работе?

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

3. Есть ли у меня возможность ежедневно заниматься на работе тем, что я умею делать лучше всего?

4. Хвалили ли меня за хорошо сделанную работу в последние 7 дней?

5. Проявляет ли непосредственный руководитель или кто-либо другой на работе заботу обо мне как о личности?

6. Есть ли на работе человек, который поощряет мой личностный или профессиональный рост?

7. Считаются ли на работе с моим мнением?

8. Позволяет ли миссия компании чувствовать важность моей работы?

9. Считают ли мои коллеги своим долгом выполнять работу качественно?

10. Работает ли вместе со мной хотя бы один из моих лучших друзей?

11. Беседовал ли кто-нибудь со мной за последние 6 месяцев о моем прогрессе?

12. Были ли у меня за последний год возможности для учебы и развития?

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

• Хвалили ли меня за хорошо сделанную работу в последние 7 дней? Нет. Типичная проблема аутсорсинга, обусловленная “утяжеленностью” процесса коммуникации. Общение с коллегой за океаном требует значительно больших усилий, чем общение с соседом по офису. В результате необязательная часть общения слетает как шелуха и остается только самое необходимое: планы, задания, вопросы, проблемы…

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

• Позволяет ли миссия компании чувствовать важность моей работы? Скорее нет. Никто не отдает на аутсорсинг жизненно важные проекты.

А на сколько баллов тянет ваша работа?

Где-то с месяц назад наткнулся на пост Why learning Haskell/Python makes you a worse programmer. Люк Плант (Luke Plant) поднимает крайне актуальную для многих из нас проблему — изучение продвинутых языков не делает вас лучшим программистом на том, что приходится использовать, а, напротив, деморализует и снижает качество работы.

Точка зрения сотрудника

Очень рекомендую прочитать как статью, так и комментарии. Если кратко, приводятся два основных аргумента:

1. После того, как ты понял и полюбил Python, писать на C# неприятно. Код громоздок и некрасив. Процедурный подход вызывает кучу потенциальных глюков. Кроме того, начав думать на Python, приходится работать “живым компилятором”, переводя эти мысли в C#.

2. Начав использовать функциональное программирование, пытаешься использовать его везде где только можно. C# не поддерживает многие концепции функционального программирования, в результате чего попытки применять функциональный стиль выглядят уродливо и непонятно. Многие задачи проще решать процедурно.

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

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

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

Добавлю еще, что все относительно. Можно заменить языки в обсуждаемом примере на другие, но проблема останется той же. Есть языки лучше, чем Python и Haskell, есть и множество языков, куда хуже C#. В реальной жизни все еще сложнее, потому что важно не столько качество языка, сколько пригодность его и связанной с ним платформы для решения конкретной задачи.

Точка зрения компании

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

Ряд задач требуют использования неоптимальных с точки зрения эстетики и уровня абстракции языков. Драйвера и embedded-приложения пишутся на C. Windows-приложения — на том, что поставляет в данный момент Microsoft (сейчас это C#). SAP кастомизируется с помощью ABAP, недалеко ушедшего в своем развитии от COBOL. Можете продолжать до бесконечности.

Кроме того, есть ниши, где выбор языка может повлиять на маркетинговую привлекательность продукта. Java продается. C# продается. Hashkell… — а что это такое? Думаю, логика выбора языка в таком случае будет очевидна.

Что думаете по этому поводу, коллеги?