Как менеджер-гуманитарий, вы понимаете, что разработчики — новый вид, живущий в офисах по всему миру. Они часто нуждаются в вашей помощи, когда речь идет о социальном взаимодействии с другими Homo sapiens. Руководитель-непрограммист может использовать этот набор «лучших практик», если хочет эффективно испортить свои отношения с разработчиками.
1. Начинайте говорить с разработчиком, только когда он в наушниках
Все мы знакомы с этим странным поведением. Общей отличительной чертой всех разработчиков является то, что они интроверты. Когда они надевают наушники, они сигнализируют вам, что им надоела их текущая работа и срочно требуется социальное взаимодействие. Не заставляйте разработчика ждать слишком долго и поторопитесь к нему со свежими офисными сплетнями или новеньким багом в софте.
2. Никогда не спрашивайте у разработчика его мнение о новой идее
Программисты, как правило, имеют твёрдое мнение о вещах, которые им предстоит разработать. Иногда они говорят, что фича плоха, потому что она затронет другие части системы или займет слишком много времени для ее реализации. Никогда не обсуждайте с разработчиками эти темы. Это оправдания. Обычная модель поведения среди разработчиков, чтобы избежать предстоящей работы.
3. Если вам что-то нужно As Soon As Possible, попросите разработчика сделать это
Мы все бывали в такой ситуации, когда начальнику нужен обновленный отчет и вы решили, что с вас хватит на сегодня этой работы. Не стесняйтесь перегрузить эту работу на разработчика. Сообщите о статусе задачи «как только — так сразу» (ASAP), и разработчик тут же начнёт работу над вашим проектом.
4. Предполагайте, что каждая задача по разработке занимает одинаковое количество времени
Вчера разработчик добавил новый функционал менее чем за 2 часа? Это, конечно, означает, что другая фича, которую вы запланировали, займет столько же времени разработки. Требуйте закончить её за 2 часа.
5. Меняйте план
Иногда вашим разработчикам нужна «встряска». Если вам показалось, что им скучно (что-то работает всё время без проблем), то измените план. Вы можете сделать это, создав новые задачи. Все, которые приходят вам на ум. Перетасуйте тикеты, занесённые в систему по планированию работ, между разработчиками. Конечно, вы можете делать это каждые несколько дней, чтобы сохранять бдительность коллектива.
6. Продолжайте говорить разработчикам, что вы тоже программист
Поскольку все разработчики более или менее боятся выходок менеджеров-нетехнарей, вы можете внедриться в их ряды «притворившись» разработчиком. Скажите им, что вы тоже программист, и покажите им, что вы написали на HTML. Они чаще всего это оценят. Только некоторые разработчики скажут вам, что HTML не является настоящим языком программирования. Если это произошло, то проигнорируйте это, потому что вы просто встретились с так называемым системным инженером или backend-разработчиком.
7. Объясните разработчикам, какие языки и фреймворки они должны использовать
Иногда бывает приятно дать разработчикам советы по языкам программирования, фреймворкам или библиотекам. Если ваш новый сосед говорит вам, что его компания теперь использует jQuery, это явный признак того, что вы должны использовать ту же технологию в своем приложении для Android или iOS.
8. Скажите, что новый веб-сайт должен работать в IE8
Разработчики — люди, склонные к ностальгии. Они любят некоторые немодные вещи, например, старые аркадные игры из восьмидесятых. В целом они глубоко уважают технологии, созданные в прошлом. Сделайте им приятное и скажите, что новый веб-сайт также полностью корректно должен работать в старых версиях знаменитого Internet Explorer.
9. Если у вас есть вопросы об определенной функции Word/Excel/Powerpoint, обратитесь к разработчику
Всякий раз, когда вы попадаете в ситуацию, в которой не понимаете как сделать, чтобы что-то работало в Excel или аналогичном инструменте, обратитесь к разработчику за помощью. Все разработчики являются экспертами в инструментах офисных программ и ??счастливы, когда могут поделиться своими знаниями. Также они рады помочь с офисным МФУ.
10. Всегда организовывайте собрания
Как это ни странно, но большинство разработчиков ненавидят общаться через электронную почту или чаты. Если вы в редкой ситуации, когда вам всё-таки не обойтись без совета или мнения разработчика — организуйте собрание. Комната для переговоров даст разработчику достаточно места, чтобы выразить свои мысли и сделать презентацию по решению вашего вопроса.
Вывод
Прочтя эти тезисы, вы, возможно, придёте к выводу, что вам не следует делать ничего из этого. Программирование требует глубокого понимания технологий и долгих размышлений. Для этого требуется время. Будьте осторожны, прерывая работу разработчика по его текущей задаче. В этом случае, есть все шансы, что вы понравитесь разработчикам. Теперь отправьте им 1 смешную гифку или комикс, чтобы сделать их более счастливыми.
Например, такой.
Комментарии (25)
parakhod
11.10.2017 11:27#define руководитель
Руководителем можно назвать lead-programmer'а — тогда не может.
А можно и, например, владельца/директора небольшой компании, который сам программировать особо не умеет (это не только к программированию и IT относится, кстати), но выступает как эффективный посредник между взбалмошным конечным заказчиком и разработчиками, доверяя (в адекватной степени) своим разработчикам всю техническую часть, и не мешая им работать, но при этом избавляя их от п.п. 1,3,4,5,8,9, беря на себя 10 и прочие радости процесса. Тогда почему бы и нет.
lair
11.10.2017 13:15руководителя-гуманитария
менеджер-гуманитарий
Руководитель-непрограммист
менеджеров-нетехнарейПростите, что конкретно вы понимаете под "гуманитарием", и почему вы выбрали именно это слово для перевода термина non-developer, используемого в оригинальной статье?
Cloud4Y Автор
11.10.2017 13:27-1Человек, который для получения профессионального образования изучал в основном науки, специализирующиеся на человеке и его жизнедеятельности в обществе.
Конкретно non-developer переводился как не разработчик, не программист, что было расширено до гуманитария, не технаря. Ваша позиция какая?lair
11.10.2017 13:59Конкретно non-developer переводился как не разработчик, не программист, что было расширено до гуманитария, не технаря.
И на основании чего вы делаете такое расширение? Почему "не разработчик" — это "не технарь"? Почему "не технарь" — это гуманитарий?
Ваша позиция какая?
"Моя позиция такая", что вы из нейтрального термина сделали дискриминирующий. Не надо так.
Cloud4Y Автор
11.10.2017 14:05-1Почему «не технарь» — это гуманитарий?
Вы считаете, что общепринятого условного деления на технарей и гуманитариев не существует?lair
11.10.2017 14:15Как "деления" (дихотомии) — не существует. Можно не быть технарем, и не быть гуманитарием при этом. Более того, можно быть гуманитарием (в вашем определении) и технарем (в аналогичном определении) одновременно. Наконец, можно быть гуманитарием (в вашем определении) и быть программистом.
Cloud4Y Автор
11.10.2017 14:24-1Цели описывать все комбинации явлений во взаимоотношениях «руководитель — программист» не было. Тем более в статье с юмористическим стилем. Take It Easy.
lair
11.10.2017 14:26Ну то есть вы так походя взяли и сказали, что гуманитарий — это то же самое, что "не программист", и take it easy? Ну-ну.
Cloud4Y Автор
11.10.2017 14:42-1Если человек утром говорит жене, что вечером заедет в супермаркет, чтобы купить необходимые продукты, и не рассказывает обо всех случаях форс-мажора, когда он этого сделать не сможет, это означает, что он говорит об ожидаемом варианте. Согласитесь странно, если бы он начал расписывать все варианты, при которых он этого не сделает. Например, «но я не заеду в супермаркет, если меня захватит НЛО». Человек выбирает меру достоверности своих слов. На мой взгляд, эта мера в этом переводе в норме. Исключения почти всегда можно найти.
lair
11.10.2017 14:48Человек выбирает меру достоверности своих слов. На мой взгляд, эта мера в этом переводе в норме.
А на мой — нет. В оригинале выбрано нейтральное non-developer. Вы заменяете его на "гуманитарий" (тем самым немедленно делая эту статью раздражающей для гуманитариев), при этом не имея для этого никакого обоснования кроме ваших собственных стереотипов.
Cloud4Y Автор
11.10.2017 14:56Все же не только мои стереотипы. Подобное деление, при котором разработчиков относят к технарям, существует у значительной доли общества.
Всё же немедленно делая эту статью раздражающей для гуманитариев именно по вашему мнению и стереотипам. Вот вы оказались на месте «переводчика», которого осуждаете. Тем не менее, прошу извинить, если раздражает.lair
11.10.2017 15:01Подобное деление, при котором разработчиков относят к технарям, существует у значительной доли общества.
Разработчиков можно отнести к технарям, но означает ли это, что гуманитарий не может быть разработчиком?
Всё же немедленно делая эту статью раздражающей для гуманитариев именно по вашему мнению и стереотипам.
Никаких стереотипов, конкретная реакция, наблюдаемая как минимум на одном известном мне гуманитарии.
Тем не менее, прошу извинить, если раздражает.
Лучше просто исправьте текст и заголовок.
Cloud4Y Автор
11.10.2017 15:04Никаких стереотипов, конкретная реакция, наблюдаемая как минимум на одном известном мне гуманитарии.
Достаточно для полной индукции?
Разработчиков можно отнести к технарям, но означает ли это, что гуманитарий не может быть разработчиком?
В этом случае, он будет в пересечении двух этих условных множеств.lair
11.10.2017 15:06Достаточно для полной индукции?
А зачем мне полная индукция?
В этом случае, он будет в пересечении двух этих условных множеств.
… и текст в статье будет продолжать к нему относиться. Правда же, круто?
Cloud4Y Автор
11.10.2017 15:12А зачем в переводе полная индукция, если был случай и не один, когда руководитель, которого многие считали гуманитарием, делал многое из описанного в статье.
Текст в статье будет относиться, только если он совершает подобные действия. Текст об ошибках, которые могут быть. Каким образом это относится к тому, кто этого не делает?lair
11.10.2017 15:14А зачем в переводе полная индукция
А где она там?
Текст об ошибках, которые могут быть.
Текст — (в том числе) о делении на разработчиков и не-разработчиков. По мнению переводчика, гуманитарий — не-разработчик.
Pinaevsky
12.10.2017 06:43-1Есть подозрение, что вы, уважаемый lair, феминистка от мира гуманитариев. По крайней мере, на подобную ассоциацию меня навели ваши рьяные попытки перевести все на «серьезные щи». В обществе уйма стереотипов, будь то «женщина за рулем» или «руководитель-гуманитарий» — не важно, это имеет место быть и на этом всегда будет строиться юмор.
Cloud4Y Автор
12.10.2017 06:53У меня сложилось мнение, что просто человек любит участвовать в дискуссии. Количество комментариев в сообществе в более чем 12000 это подтверждает. Почему нет, это ведь одна из целей сообщества
parakhod
11.10.2017 14:30+1У меня одно высшее — инженер-электронщик, а второе — история и археология.
Мне теперь что, разорваться что ли? (ц) ))
tushinx
12.10.2017 06:44Специально зарегистрировался, что бы оставить комментарий. На мой взгляд, эта статья не «лучшая практика», а как не нужно делать, если вы менеджер-гуманитарий.
Я сам являюсь программистом, и если я сижу в наушниках — я работаю, и надел их, что бы мне никто не мешал. Лезть в это время с новыми фичами — глупо.
Предполагать что все задачи на выполнение требуют одного срока тоже глупо.
И уж тем более перемешивать задачи, на основании которых у программиста выстроен план действий это какое-то ребячество, игра в менеджера.Cloud4Y Автор
12.10.2017 06:44«Лучшие практики» в кавычках. Вы правильно понимаете, это вредные советы. Как делать не следует.
mrsweet
12.10.2017 06:44Многие из этих пунктов руководитель успешно испытывает на мне. Однако, это работает и в обратную сторону, ведь по образованию экономист
parakhod
Как-то по-моему слишком много снобизма. Водораздел между адекватным и неадекватным руководителем/заказчиком проходит не по линии технарь-гуманитарий, а скорее по тому, является ли человек полным идиотом, или нет. Ну и не оказался ли он на своём месте вследствие принципа Питера.
А по пункту номер 7 я вообще не встречал большего кошмара, чем заказчик/руководитель проекта, считающий себя хорошим разработчиком (на основании того что он только что закончил "очень дорогое" учебное заведение, или своего постоянного общения в IT тусовке). Я даже один раз видел как это просто убило неплохой изначально проект, в который инвесторы вложили около 300 тысяч долларов — ну вот надо было ему воткнуть туда именно GraphQL во все дыры — и всё. В результате на то, что потребовало бы недели работы, было убито месяца три (и всё равно работало криво).
Cloud4Y Автор
Сам вопрос о том, может ли не программист быть руководителем разработчиков все же существует. Голосование на данный момент это подтверждает. 0% имели положительный опыт с такими руководителями.
Вот интересный пример, связанный с крупный утечкой.
Susan Mauldin, Chief Security Officer at Equifax, was a music major.