Разработчики и неразработчики мыслят совсем по-разному. Поэтому то, что кажется всем остальным нормальным (вопросы, комментарии и просто фразы для поддержания разговора), может довести специалиста до белого каления. Менеджерам на заметку: если у программиста нервно задергался глаз после вашего вопроса, возможно, следует его переформулировать или вообще больше не задавать.
Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.
Итак, встречайте топ-7 фраз менеджеров, которые не оставляют выбора программистам.
/ Flickr / Kenny Louie / CC
Когда менеджер уверенно заявляет, что делать тут нечего, то, скорее всего, все окажется совсем наоборот. Поэтому иногда специалист вынужден отказаться от выполнения такого задания, ссылаясь на то, что это не в его компетенции. «Правильный» менеджер должен спросить себя, сколько времени это займет, и сколько будет стоить. Еще неплохо поинтересоваться мнением программиста о целесообразности внесения какого-либо изменения, и тогда не придется пользоваться табличкой перевода слов программиста, потому что при такой формулировке вопроса ответ вряд ли будет: «Это невозможно сделать сейчас».
Но при работе с новоиспеченными программистами такая фраза может произвести обратный эффект, что, пожалуй, еще хуже. Когда вчерашнему выпускнику вуза на работе поручают сделать что-то с такой формулировкой, он скорее согласится с тем, что это плевое дело, чем признается, что понятия не имеет, как выполнить такое задание.
Конечно, это не так плохо, все учатся на своих ошибках. Например, описывая в интервью свой опыт работы junior-разработчиком, Джонатан Барронвиль (Jonathan Barronville) говорит, что ошибаться и не знать чего-то на начальных этапах работы нормально. Но чтобы не услышать ложь в ответ на невыполнимую просьбу или некорректно поставленную задачу, менеджерам стоит обсуждать условия и прислушиваться к мнению специалистов.
Даже если код, сайт или программа отлично работают, имеют удобный интерфейс (то, что видят пользователи), за всем этим может скрываться такое количество ошибок, что остается загадкой, как это все работает. Да и вообще, как сказал известный нидерландский ученый-информатик Эдсгер Дейкстра (Edsger Dijkstra), если отладка кода — это процесс устранения багов, то программирование — это процесс внедрения багов.
Но объяснить человеку, далекому от разработки, что избежать ошибок в коде не так-то просто, задача почти нереальная. Поэтому такому человеку о своей работе программист скорее скажет: «Тут есть пара недочетов» (примерно так переводится «В моем коде есть баги» с языка программистов).
Общение с людьми, далекими от программирования, иногда доставляют разработчикам, ну вы сами понимаете, «боль». А когда менеджер просит мыслить как эти люди, становится еще хуже. Поэтому когда разработчик говорит, что понял, чего хочет клиент, это не всегда так. Разработчик знает только то, что сказал клиент, а что он думает, и уж тем более как он мыслит, часто непостижимо.
Не зря же существует как сам менеджер, так и отдел контроля качества, команда которого выступает в качестве третьей беспристрастной стороны и следит за тем, чтобы то, что делает программист, соотносилось с желаниями клиента. К тому же они ответственны за выяснение того, что может натворить пользователь. И их работа — вести себя как самый плохой пользователь, которого только можно представить.
Мыслить как такой пользователь программист точно не сможет, так как он сам знает о коде все, а пользователь — ничего. (Подробнее о работе отдела контроля качества читайте тут «How the QA Process Works» и «QA Teams Are Responsible For Keeping the Site From Breaking»).
Вообще, представление клиентов о работе отлично отражает старое, но не теряющее актуальности видео про 7 красных перпендикулярных линий, некоторые из которых должны быть нарисованы зелеными чернилами, а некоторые — прозрачными.
Клиенты и начальники хотят сразу видеть, что программист начал работать. Точнее, что он сел перед экраном и начал писать код, уверен всемирно известный эксперт в области ИТ Дэвид Штром (David Strom). Он составил список 10 вещей, которые непрограммисты любят говорить программистам, где в седьмом пункте объясняет, что такие люди не понимают важности предварительной работы.
Написание кода — вообще последний этап работы, подготовительная часть до этого состоит из совсем других вещей, которые посторонним могут казаться бездельем, объясняет Маклауд Сойер в 4 пункте своей статьи. Чтобы продумать выполнение определенных задач и требований, иногда нужно расслабиться, посмотреть в окно, послоняться вокруг, поспать или даже поиграть в Halo — никогда не знаешь, в какой именно момент придет решение.
Харлан Миллс (Harlan Mills), основатель Software Engineering Technology однажды сказал: «Программирование напоминает игру в гольф. Цель не загнать шарик в лунку, а сделать это за наименьшее количество ударов». Чтобы достичь цели быстрее, необходимо как можно лучше продумать все шаги и «удары». Осталось только объяснить это менеджеру.
Конечно, у вашего босса есть право считать так, но ему не приходилось работать с кодом без комментариев. В то время как их наличие сильно экономит время, если с этим кодом придется работать кому-то другому и даже вам самим спустя несколько месяцев или лет, пишет блоггер Джейк Рошело (Jake Rocheleau) (см. пункты 20 и 25). Иногда программиста вынуждают согласиться работать без комментариев (в виду, например, сжатых сроков), что осложняет и последующее устранение ошибок в коде.
Когда программист сам заявляет о том, что код не требует комментариев или является самодокументирующимся, на данный момент он отлично понимает, как все работает. Но на каких-то важных моментах остановиться все равно стоит: например, показать, что непривычный порядок выполнения определенной операции не является ошибочным, а был переделан намеренно из-за каких-либо багов.
Другая проблема комментариев заключается в том, что они редко обновляются вместе с исправлением кода. В этом случае они даже могут стать опасными и завести разработчика совсем не туда, объясняет автор книг и основатель Simple Programmer Джон Сонмнез (John Sonmez) в 4 правиле программистов (из 11 существующих). Но писать или не писать комментарии должен решать программист, а не менеджер или клиент.
Фраза, которая способна вывести из себя почти любого разработчика. Объяснить менеджеру, что просчитать все возможные ошибки и проблемы заранее просто невозможно. Отсюда, например, рождаются мифы о том, что две самые великие сказки — это «Властелин колец» Толкиена и расписание любого программиста (такой пример приводит пользователь Quora Скотт Гарднер (Scott Gardner)). Возможно, иногда преуменьшение бывает свойственно разработчикам. На этот случай шведский программист подготовил специальную табличку перевода программерского времени в реальное.
Однако если отбросить все шутки в сторону, дело совсем не в том, что программисты совсем не дружат со временем или живут в параллельной реальности. Отличное объяснение этому явлению дал эксперт Electronic Auction Services Брэд Лэндерс (Brad Landers), который уверен (первый комментарий в источнике), что главная проблема — в формулировке поставленной задачи. Чем более расплывчато менеджер или клиент составляет требования к проекту, тем больше непредвиденных обстоятельств может возникнуть. Поэтому совсем нечестно перекладывать всю ответственность за несоблюдение сроков на плечи программиста.
Очень сложно объяснить простым смертным, что тестирование любых изменений (еще лучше поэтапное) — показатель профессионализма и сэкономит кучу времени при выявлении багов. Но менеджеры очень часто уверены, что они просят внести незначительное изменение, которое займет несколько минут. Но небольших изменений не бывает, считает Дес Трэйнор (Des Traynor), сооснователь службы передачи сообщений Intercom. В своей статье он приводит пример такого «маленького» изменения: клиент просить ограничить написание отзыва о продукте 140 символами.
Специалист сразу увидит, что все не так легко и просто, и это изменение повлечет за собой еще десятки других: например, нужно решить, что будет при превышении лимита в 140 знаков? Текст обрежется, или пользователь увидит сообщение об ошибке? Что будет написано в этом сообщении? Как оно будет выглядеть? Кто займется его дизайном? Вопросы, а вместе с ними и новые небольшие изменения, накатываются, словно снежный ком. И каждое из них требует тестирования.
Итак, главное при общении с программистами — иметь представление об их работе и мышлении. Конечно, требовать этого от всех людей (как бы ни хотелось) бессмысленно. Но вот от тех, с кем разработчики работают бок о бок, хотелось бы понимания о специфике работы, что поможет избежать недопонимания, а иногда и конфликтов, сделает рабочую обстановку более комфортной и укрепит отношения в коллективе.
Мы в 1cloud стремимся к этому при организации работы внутри коллектива и рассказываем об этих и других улучшениях в нашем блоге на Хабре:
Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.
Итак, встречайте топ-7 фраз менеджеров, которые не оставляют выбора программистам.
/ Flickr / Kenny Louie / CC
«Нужно кое-что глянуть. Это быстро и несложно»
Когда менеджер уверенно заявляет, что делать тут нечего, то, скорее всего, все окажется совсем наоборот. Поэтому иногда специалист вынужден отказаться от выполнения такого задания, ссылаясь на то, что это не в его компетенции. «Правильный» менеджер должен спросить себя, сколько времени это займет, и сколько будет стоить. Еще неплохо поинтересоваться мнением программиста о целесообразности внесения какого-либо изменения, и тогда не придется пользоваться табличкой перевода слов программиста, потому что при такой формулировке вопроса ответ вряд ли будет: «Это невозможно сделать сейчас».
Но при работе с новоиспеченными программистами такая фраза может произвести обратный эффект, что, пожалуй, еще хуже. Когда вчерашнему выпускнику вуза на работе поручают сделать что-то с такой формулировкой, он скорее согласится с тем, что это плевое дело, чем признается, что понятия не имеет, как выполнить такое задание.
Конечно, это не так плохо, все учатся на своих ошибках. Например, описывая в интервью свой опыт работы junior-разработчиком, Джонатан Барронвиль (Jonathan Barronville) говорит, что ошибаться и не знать чего-то на начальных этапах работы нормально. Но чтобы не услышать ложь в ответ на невыполнимую просьбу или некорректно поставленную задачу, менеджерам стоит обсуждать условия и прислушиваться к мнению специалистов.
«Ты так долго писал код, в нем же больше нет ошибок?»
Даже если код, сайт или программа отлично работают, имеют удобный интерфейс (то, что видят пользователи), за всем этим может скрываться такое количество ошибок, что остается загадкой, как это все работает. Да и вообще, как сказал известный нидерландский ученый-информатик Эдсгер Дейкстра (Edsger Dijkstra), если отладка кода — это процесс устранения багов, то программирование — это процесс внедрения багов.
Но объяснить человеку, далекому от разработки, что избежать ошибок в коде не так-то просто, задача почти нереальная. Поэтому такому человеку о своей работе программист скорее скажет: «Тут есть пара недочетов» (примерно так переводится «В моем коде есть баги» с языка программистов).
«Ты должен мыслить как клиент»
Общение с людьми, далекими от программирования, иногда доставляют разработчикам, ну вы сами понимаете, «боль». А когда менеджер просит мыслить как эти люди, становится еще хуже. Поэтому когда разработчик говорит, что понял, чего хочет клиент, это не всегда так. Разработчик знает только то, что сказал клиент, а что он думает, и уж тем более как он мыслит, часто непостижимо.
Не зря же существует как сам менеджер, так и отдел контроля качества, команда которого выступает в качестве третьей беспристрастной стороны и следит за тем, чтобы то, что делает программист, соотносилось с желаниями клиента. К тому же они ответственны за выяснение того, что может натворить пользователь. И их работа — вести себя как самый плохой пользователь, которого только можно представить.
Мыслить как такой пользователь программист точно не сможет, так как он сам знает о коде все, а пользователь — ничего. (Подробнее о работе отдела контроля качества читайте тут «How the QA Process Works» и «QA Teams Are Responsible For Keeping the Site From Breaking»).
Вообще, представление клиентов о работе отлично отражает старое, но не теряющее актуальности видео про 7 красных перпендикулярных линий, некоторые из которых должны быть нарисованы зелеными чернилами, а некоторые — прозрачными.
«Ты не должен отвлекаться — иначе ничего не получится»
Клиенты и начальники хотят сразу видеть, что программист начал работать. Точнее, что он сел перед экраном и начал писать код, уверен всемирно известный эксперт в области ИТ Дэвид Штром (David Strom). Он составил список 10 вещей, которые непрограммисты любят говорить программистам, где в седьмом пункте объясняет, что такие люди не понимают важности предварительной работы.
Написание кода — вообще последний этап работы, подготовительная часть до этого состоит из совсем других вещей, которые посторонним могут казаться бездельем, объясняет Маклауд Сойер в 4 пункте своей статьи. Чтобы продумать выполнение определенных задач и требований, иногда нужно расслабиться, посмотреть в окно, послоняться вокруг, поспать или даже поиграть в Halo — никогда не знаешь, в какой именно момент придет решение.
Харлан Миллс (Harlan Mills), основатель Software Engineering Technology однажды сказал: «Программирование напоминает игру в гольф. Цель не загнать шарик в лунку, а сделать это за наименьшее количество ударов». Чтобы достичь цели быстрее, необходимо как можно лучше продумать все шаги и «удары». Осталось только объяснить это менеджеру.
«Я плачу за код, а не за комментарии»
Конечно, у вашего босса есть право считать так, но ему не приходилось работать с кодом без комментариев. В то время как их наличие сильно экономит время, если с этим кодом придется работать кому-то другому и даже вам самим спустя несколько месяцев или лет, пишет блоггер Джейк Рошело (Jake Rocheleau) (см. пункты 20 и 25). Иногда программиста вынуждают согласиться работать без комментариев (в виду, например, сжатых сроков), что осложняет и последующее устранение ошибок в коде.
Когда программист сам заявляет о том, что код не требует комментариев или является самодокументирующимся, на данный момент он отлично понимает, как все работает. Но на каких-то важных моментах остановиться все равно стоит: например, показать, что непривычный порядок выполнения определенной операции не является ошибочным, а был переделан намеренно из-за каких-либо багов.
Другая проблема комментариев заключается в том, что они редко обновляются вместе с исправлением кода. В этом случае они даже могут стать опасными и завести разработчика совсем не туда, объясняет автор книг и основатель Simple Programmer Джон Сонмнез (John Sonmez) в 4 правиле программистов (из 11 существующих). Но писать или не писать комментарии должен решать программист, а не менеджер или клиент.
«Скажи точно, когда закончишь»
Фраза, которая способна вывести из себя почти любого разработчика. Объяснить менеджеру, что просчитать все возможные ошибки и проблемы заранее просто невозможно. Отсюда, например, рождаются мифы о том, что две самые великие сказки — это «Властелин колец» Толкиена и расписание любого программиста (такой пример приводит пользователь Quora Скотт Гарднер (Scott Gardner)). Возможно, иногда преуменьшение бывает свойственно разработчикам. На этот случай шведский программист подготовил специальную табличку перевода программерского времени в реальное.
Однако если отбросить все шутки в сторону, дело совсем не в том, что программисты совсем не дружат со временем или живут в параллельной реальности. Отличное объяснение этому явлению дал эксперт Electronic Auction Services Брэд Лэндерс (Brad Landers), который уверен (первый комментарий в источнике), что главная проблема — в формулировке поставленной задачи. Чем более расплывчато менеджер или клиент составляет требования к проекту, тем больше непредвиденных обстоятельств может возникнуть. Поэтому совсем нечестно перекладывать всю ответственность за несоблюдение сроков на плечи программиста.
«Хватит тестировать, пора запускать»
Очень сложно объяснить простым смертным, что тестирование любых изменений (еще лучше поэтапное) — показатель профессионализма и сэкономит кучу времени при выявлении багов. Но менеджеры очень часто уверены, что они просят внести незначительное изменение, которое займет несколько минут. Но небольших изменений не бывает, считает Дес Трэйнор (Des Traynor), сооснователь службы передачи сообщений Intercom. В своей статье он приводит пример такого «маленького» изменения: клиент просить ограничить написание отзыва о продукте 140 символами.
Специалист сразу увидит, что все не так легко и просто, и это изменение повлечет за собой еще десятки других: например, нужно решить, что будет при превышении лимита в 140 знаков? Текст обрежется, или пользователь увидит сообщение об ошибке? Что будет написано в этом сообщении? Как оно будет выглядеть? Кто займется его дизайном? Вопросы, а вместе с ними и новые небольшие изменения, накатываются, словно снежный ком. И каждое из них требует тестирования.
Итак, главное при общении с программистами — иметь представление об их работе и мышлении. Конечно, требовать этого от всех людей (как бы ни хотелось) бессмысленно. Но вот от тех, с кем разработчики работают бок о бок, хотелось бы понимания о специфике работы, что поможет избежать недопонимания, а иногда и конфликтов, сделает рабочую обстановку более комфортной и укрепит отношения в коллективе.
Мы в 1cloud стремимся к этому при организации работы внутри коллектива и рассказываем об этих и других улучшениях в нашем блоге на Хабре:
