Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.
Итак, встречайте топ-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 стремимся к этому при организации работы внутри коллектива и рассказываем об этих и других улучшениях в нашем блоге на Хабре:
Комментарии (112)
claygod
08.11.2016 12:22+14Как вывести из себя программиста
Немного похоже на «Как стать непрограммистом».
martin_wanderer
08.11.2016 13:50+8Вот я тоже сначала подумал, что в заголовке имеется в виду «Как перестать быть программистом и начать жить».
Pakos
09.11.2016 15:27Я до чтения статьи думал что это мегамозговское «как вывести из себя программиста и стать (розовым слоном, например)». «Как изжить в себе программиста», а оказывается банальное «как задолбать».
Saffron
08.11.2016 12:30+2Я несколько раз пытался вывести программиста из себя — он иногда мешает общаться и искажает ход мыслей пользователей. Но так и не смог.
WebMonet
08.11.2016 12:34+6Если ты не закончишь вовремя — придется отдать на фриланс
ITurchenko
08.11.2016 13:05+31Через неделю
«Нужно кое-что глянуть в работе этого фрилансера. Это быстро и несложно»
4ebriking
08.11.2016 14:36Есть один хорошо знакомый конструктор — сидит в своём «Солиде» полный рабочий день безотрывно.
Вот один-в-один всё как тут, даже включая «отдать во фриланс… глянуть быстренько, что там наваяли фрилансеры».
Scf
08.11.2016 13:37-1Имеет смысл задуматься и посмотреть на это со стороны бизнеса. Программа нужна для того, чтобы экономить деньги или зарабатывать деньги. Пока нет программы — бизнес терпит убытки. Далее, программистам платят за время. В итоге получается, что программисты напишут программу неизвестного качества, за неизвестное время и за неизвестное количество денег. Аджайл и прочий скрам уменьшают неопределенность, но увеличивают стоимость разработки за счет дополнительного времени, которое тратится на ритуалы.
Ну и как тут не нервничать? :-)
2ball
08.11.2016 14:40+15Вот взгляд со стороны WEB.
Описание бизнес процесса ->
Спецификация ->
Дизайн ->
Верстка ->
Frontend ->
Backend ->
QA ->
Bug fixing ->
QA ->
Staging ->
QA ->
Bug fixing ->
QA ->
Production
Итак, вам нужны:
1) BA
2) Product manager
2) Designer
3) Верстальщик
4) Frontend developer
5) Backend developer
6) QA
7) Release manager
8) *nix администратор
Если посмотреть hh, то можно запросто заметить тенденцию на покрытие пунктов 3,4,5,6,7,8 за счет одного человека. Бизнес можно понять, бизнес пытается не раздувать штат, но и покупая запорожец не стоит ждать от него работы на уровне мерседеса. Покрыть все бизнес процессы на которые требуется 8 специалистов за счет 2-3 == принять на себя риски по некачественной реализации практически каждого из них.
И это еще без взаимодействия расчет. А если добавить сюда синхронизацию со всякими 1С, внешние сервисы и поддержку клиентов, то можно еще 4 спецов добавить. Потом выстроить их взаимодействие между собой и управлять командой с помощью лидов. И вот после этого, когда условия для разработки созданы в полной мере, можно смело требовать полного соблюдения сроков и работоспособности.
Но, программисты не требуют бизнес аналитиков и грамотных спецификаций, да и покрывают несколько специализаций самостоятельно. Бизнес со своей стороны терпит по срокам, экономя на штате. Все просто :)
Когда в следующий раз начнете нервничать, просто умножьте каждый пункт на 70-90к рублей (на средних спецов) и сопоставьте с потраченными нервами))) В среднем это от 200 до 500к в месяц. Потом сравните с реальными потерями от простоя и может быть трата нервов будет обходится дешевле хорошо выстроенного процесса))) Have a nice day))
AlexLysenko
16.02.2017 14:08Блэкберри относительно недавно выпустили смартфон с вертикальным экраном 4:3 и физической клавой под ним.
fireSparrow
08.11.2016 23:08+12Вспомнился анекдот:
Менеджер говорит программисты:
— Искусственный интеллект уже близко, и скоро программисты будут вообще не нужны. Я просто дам искусственному интеллекту полное и подробное описание того, что программа должна делать, и он мне сам напишет код.
Программист:
— А ты знаешь, что такое полное и подробное описание того, что должна делать программа? Это и есть код.Oxoron
09.11.2016 12:03Посмеялся после
Я просто дам искусственному интеллекту полное и подробное описание того, что программа должна делать,
Pakos
09.11.2016 15:33Я даже знаю у кого это получилось (всех технарей). Жили счастливо (когда всё работало), но не долго, ибо доработки под их хотелки сами не появляются, а искать кого «быстро посмотреть» стоит денег. И времени. И разгребания последствий. Что тоже стоит денег. И времени. И…
belurd
08.11.2016 15:11Где же что-нибудь про оценку трудозатрат? Меня это больше всего «радует», например. «Сколько тебе надо времени, чтобы это сделать?», я бы так это назвал.
betsuni
08.11.2016 15:40+8Это ты делал всю неделю? Да это за 10 минут можно написать. Ну 20.
Chamie
15.11.2016 16:07+1— Ты потратил на этот баг неделю, а в итоге поменял только 2 символа в одной строчке? Чем ты занимался всё это время?
fireSparrow
15.11.2016 17:15Вспоминается байка про «удар молотком — 1 доллар; знал куда бить — 9999 долларов»
AvatarBlueray
08.11.2016 15:40+6>> «Скажи точно, когда закончишь»
Есть две простые задачи:
1) посчитать количество букв в предложении.
2) засечь время.
Так вот я назову вам точный срок если вы правильно ответите одним пердложением на вопрос:«Сколько букв в вашем ответе и сколько прошло секунд с момента когда я его задал?»
Эта простая задача не должна занять много времени, считать буквы вы умеете, секундомером мпользоваться тоже.
MOTORIST
08.11.2016 16:38+2«Скажи точно, когда закончишь» — актуальная для меня на данный момент.
— «Нужно интегрировать нашу систему вон с той. У нас нет документации, но ты разберись. Когда сможешь сделать? Ну хотя бы примерные сроки ты можешь сказать?»zxweed
08.11.2016 19:42+2надо отвечать «потребуется неделя, приступить смогу через восемь месяцев, до этого момента все задачи расписаны»
dron_k
08.11.2016 19:44Ага, да, примерные,
а потом «Ну тыже обещал сделать все за XXX времени, а потратил XXX+10% !!!!111адинадин»
dron_k
08.11.2016 19:53+1А вообще в таких случаях берется время на анализ/изучение вопроса,
к примеру 3 дня,
не хватило — берешь еще время, тут уже обычно есть представление сколько еще нужно времени на доразбор
потом можно обсуждать сроки разработки.
Ну или велкам ту аджайл метологии, где неясности будут браться малыми секторами и проясняться по мере продвижения разработки — но тут есть риск изначально выбрать неправильное базовое архитектурное решение тк изначально нет полной и ясной картины.
Landgraph
08.11.2016 21:23Вот прям плюсану. Если время есть — то однозначно берётся для более детальной проработки вопроса.
А ещё надо учитывать, что каждый вышестоящий уровень уменьшает названное исполнителем время где-то процентов на 5-10.
Программист сказал, что сделает за неделю, руководитель отдела назвал 6,5 дней, координатор уже рассчитывает на 6 дней… Директору докладывают, что всё будет готово к утру, с чем и поздравляют исполнителя, который теперь уже вынужден работать ночами!
Pakos
09.11.2016 15:39Последний плюс вариант к этому:
— Чем сейчас занят?..
— (Перечисление 2-3 задач с «приоритетом 0», которые чередуются, т.к. каждая в процессе требует то неготовую аппаратуру, то результат другой задачи + «быстро посмотреть что сломалось»).
— А, ну это не долго/не сильно загружает, вот ещё одна задача…
Поэтому всегда добавляю в ответ на «когда закончишь» — «чистого времени, при появлении других задач время увеличивается на их срок+% на переключение». А ещё от этих дел (в случае кода) получается куча веток, которые потом вообще не понятно куда девать.
viru0
08.11.2016 19:46+8Ну не знаю. Все вопросы прямиком завязаны на бизнес и меня например ни капли не раздражают.
— Нужно кое-что глянуть. Это быстро и несложно
Это значит что кто-то, директор или клиент, что-то заметил и нужно глянуть.(Нужно с бизнес точки зрения) Менеджер конечно хочет чтобы все быстро исправили, но если это большая серьезная проблема, нужно просто ему об этом сообщить.
Т.е. заводим тикет — глядим, можем быстро пофиксить — фиксим, не можем, заводим еще один — кидаем в backlog, объясняем менеджеру.
— Ты так долго писал код, в нем же больше нет ошибок?
Если долго писал значит время куда то уходило (а значит и деньги на твою ЗП), поэтому — что получил наниматель взамен должно быть прозрачно. И если в трекере больше нет багов — то ответ на этот вопрос: «Да, в коде больше нет багов, о которых нам было известно»
— Ты должен мыслить как клиент
Это вообще делает процесс написания кода более приятным. Когда ты понимаешь как и кто будет этим пользоваться. Сходил, как то, на 'User testing', при мне 40 летний дядя из глубинки тыкал на прототип продукта в iPad, потому что он тренировал школьников и реально хотел считать индивидуальную статистику для игроков. Это меняет, теперь понимаешь что размер кнопки интерфейса может быть на самом деле важнее, чем ответ от сервера в 200мс вместо 500мс и использование quick-sort вместо пузырька. И оптимизируя css на сайте под IE, теперь знаешь, что, где то там, есть реальный человек, который просто кликнул на иконку «Интернет» и хочет решить свою проблему на твоем сайте, это скучное действо(правки css) превращается в наполненное смыслом.
— Я плачу за код, а не за комментарии
Я не пойму, какой то программист забюджетировал время на комментарии? Откуда менеджер вообще знает о комментах в коде? Понятно, что менеджер возмущен. Представьте вы отдали машину в сервис, получая счет там есть пометка «Внесение записей в блокнотик 40мин — 1500руб» вы не понимаете в чем дело, вам объясняют, что механику необходимо делать пометки чтобы работа была выполнена. И вроде все логично -> Но у вас ничего кроме ощущения 'развода' не останется. Если эта часть работы и менеджера интересует результат, ну зачем менеджеру все эти внутренние подробности.
— Скажи точно, когда закончишь
Давайте поймем что такое «законченный» и тогда будет понятно когда. Нет всех деталей, не совсем понятно что такое законченный. Ну давайте сделаем сейчас то что понятно, а это уже можно оценить.
(вот вам и agile. Ок вроде ясно что за неделю-две сделаю то и то, посмотрим что получилось, и потом поймем как двигаться к «законченному») Не понимание сколько времени займет та или иная хорошо определенная задача — признак малого опыта. Если задача не совсем определена — опять же можно сказать что знаешь более менее, а что не понятно и почему. Когда фирма/работник не может сказать, когда она закончит и сколько будут стоить ее услуги, с такой фирмой, невозможно работать. Это как вызвал такси и спрашиваешь мне нужно очутиться там то, сколько стоит — а вам водитель такой: «Ну не знаю, как карта ляжет»
Или: «Это 25км, без пробок 30 мин — в итоге, подчеркиваю — без пробок и по короткому пути: 500руб, но в случае пробок доп минута — 1руб, в случае объезда 15руб — 1км»
С каким поедете?
— Хватит тестировать, пора запускать
Во всех не болотных компаниях давно есть CI/CD практики, при таких условиях такой вопрос просто не возникает.
«Конечно, давайте запускать» — но для начала для 1% траффика или для клиентов которые подписались на beta. Что-то посыпалось — отлично, теперь мы знаем о критической баге, которую никак кроме как запуском не выловишь. Исправим и снова запустим. А маркетинг с рассылками и.т.п. пусть сам планирует в какой момент какую компанию и рекламу запускать.MacIn
08.11.2016 20:55+1Я не пойму, какой то программист забюджетировал время на комментарии? Откуда менеджер вообще знает о комментах в коде?
Документирование, втч комментарии, может вестись пост-фактум. Здесь и получается, что продукт готов, но программист почему-то чем-то занят.
С каким поедете?
С тем, кто приехал на вызов.
saboteur_kiev
09.11.2016 14:16+2Товарищ гуманитарный менеджер, перелогиньтесь.
P.S. По вызову цена уже известна со слов диспетчера.MacIn
09.11.2016 18:46Товарищ гуманитарный менеджер, перелогиньтесь.
Вас, разумеется, не затруднит пояснить столь искрометный юмор.
P.S. По вызову цена уже известна со слов диспетчера
Угу
Это как вызвал такси и спрашиваешь
У кого, и зачем, если вам при вызове все говорит диспетчер?
P.S. ни разу в жизни не было такого, чтобы диспетчер называл цену — это вообще не его забота. Это, вероятно, какая-то местная особенность.saboteur_kiev
10.11.2016 05:12-1> Вас, разумеется, не затруднит пояснить столь искрометный юмор.
«Документирование, втч комментарии, может вестись пост-фактум.»
То есть сперва написал код, потом его еще раз перечитать целиком, чтобы комментарии расставить?
Если пишешь код с комментариями, это нужно делать СРАЗУ по нескольким причинам:
1) Ты пишешь код, ты знаешь что ты написал — сразу закомментируй. Комментировать потом — трата времени на перечитывание кода.
2) Например в Java, с ее javadoc, комментарии это часть языка. Анализаторы могут ругаться, что функции не задокоментированы.
3) Если ты работаешь по таскам, как ты объяснишь менеджеру, что ты фичу вчера доделал и время по ней залогировал, и закрыл и отдал в тестирование. А сегодня ты на нее снова логируешь время, хотя дефектов там тестировщики не нашли. Просто тебе комментарии вдруг нужно написать. Но если это нормальный CI, то после коммита твоих комментариев, по правильному новая версия должна пройти заново весь цикл тестирования, независимо от того, что там всего лишь комментарии добавились.Saffron
10.11.2016 05:36+2> 1) Ты пишешь код, ты знаешь что ты написал — сразу закомментируй. Комментировать потом — трата времени на перечитывание кода.
Не факт. Когда ты пишешь, и когда ты читаешь — считай что ты разный человек. У тебя голова по разному работает в этот момент. Что кажется очевидным во время написания, кажется не таким уже простым при чтении. Опять же, после написания следует использование, и паттерны использования написаного кода тоже заставляют взглянуть на него другое, теперь важными аспектами кажутся не те, что были вначале.
Писатель, конечно, может приложить все усилия, чтобы понять читателя и оставить понятные ему комментарии. Но иногда этого не хватает, и читателю приходится вставлять комментарии самому. Уже потом, при повторном чтении.
MacIn
10.11.2016 16:30+1То есть сперва написал код, потом его еще раз перечитать целиком, чтобы комментарии расставить?
Это необязательно комментарии по логике работы программы. Это могут быть банально «шапки» процедур и модулей, которые могут быть написаны в конце, до передачи в отдел QA и документации. По сути функционал есть, документирование не завершено. Вполне рабочая ситуация.
И это я еще не упоминал legacy код, который может быть вовсе без комментариев изначально, которые ты можешь добавлять для улучшения читаемости кода в целом.
1) Ты пишешь код, ты знаешь что ты написал — сразу закомментируй. Комментировать потом — трата времени на перечитывание кода.
Смотря о каких комментариях мы говорим и смотря сколько времени прошло между этими моментами.
2) Например в Java, с ее javadoc, комментарии это часть языка. Анализаторы могут ругаться, что функции не задокоментированы.
Мир ею не ограничивается.
Если ты работаешь по таскам, как ты объяснишь менеджеру, что ты фичу вчера доделал и время по ней залогировал, и закрыл и отдал в тестирование. А сегодня ты на нее снова логируешь время, хотя дефектов там тестировщики не нашли
Да без проблем. У нас даже отдельная статья есть по которой можно закреплять время — для отдельного code review.
Например, ты закончил свой участок работы по функционалу и можешь передать задачу далее в QA. При этом ты можешь доделать комментарии по логике какого-нибудь legacy, в котором ты разбирался по ходу таска. В итоге сам таск отдан дргим людям, они не простаивают.
Но если это нормальный CI, то после коммита твоих комментариев, по правильному новая версия должна пройти заново весь цикл тестирования, независимо от того, что там всего лишь комментарии добавились.
Отдельное тестирование после коммита комментариев no functional changes? Спасибо, но нет. У нас есть стандартный еженедельный цикл тестирования ключевых точек продукта плюс ежечасные юнит тесты, этого достаточно.
Xtray
10.11.2016 11:17P.S. ни разу в жизни не было такого, чтобы диспетчер называл цену — это вообще не его забота. Это, вероятно, какая-то местная особенность.
Есть города >1кк, где это стандарт де-факто. Называешь адреса, тебе сразу говорят сумму. Ни от каких пробок она не зависит (и не понятно, почему должна).MacIn
10.11.2016 16:35Вполне допускаю, просто не понимаю этого «назвать адреса», «цена заранее». Ты вызвал машину в эту вот точку пространства. На этом работа диспетчера завершилась. А куда ты там потом поедешь — да черт его знает, еще десять раз передумать можешь. Или заехал по пути за знакомым, ждешь его — почасовая оплата тикает. И так далее.
Xtray
10.11.2016 17:56Расстояние рассчитывается по карте отсюда и цена. Время ожидания фиксированное, X рублей минута — легко плюсуется. Если изменился маршрут — водитель связывается с диспетчером, стоимость пересчитывается с учетом новых данных.
MacIn
10.11.2016 20:47Расстояние рассчитывается по карте отсюда и цена
А дорога только одна? Если пассажир хочет заскочить в магазин или к банкомату?
Время ожидания фиксированное, X рублей минута — легко плюсуется.
Да, но оно заранее неизвестно
Если изменился маршрут — водитель связывается с диспетчером, стоимость пересчитывается с учетом новых данных.
Вот сейчас я совсем перестал понимать. Вот машина, вот счетчик. Он учитывает и километраж, и время. При чем тут диспетчер и зачем с ним связываться — не понимаю.Xtray
10.11.2016 21:41А дорога только одна? Если пассажир хочет заскочить в магазин или к банкомату?
Дорог много, оптимальная (кратчайшая) — одна. Обычно она и рассчитывается. Возможно, учитываются пробки и маршрут строится с их учетом.
Да, но оно заранее неизвестно
А зачем оно заранее? Стоимость проезда, допустим, 350 рублей. Минута ожидания 5 рублей. У банкомата провел 3 минуты. Доплачиваешь 15 рублей. Вроде бы не сложно суммировать :)
Вот сейчас я совсем перестал понимать. Вот машина, вот счетчик. Он учитывает и километраж, и время. При чем тут диспетчер и зачем с ним связываться — не понимаю.
Нет никаких счетчиков, все расстояние считается по карте. От точки А до точки Б. Если добавляется новая точка в процессе, она сообщается диспетчеру, он пересчитывает и сообщает новую сумму.MacIn
10.11.2016 21:47Нет никаких счетчиков,
Интересная система. А где гарантия, что диспетчер не обманывает при расчете? Счетчики-то пломбируют и поверяют.Xtray
10.11.2016 22:21Имхо, гарантом выступает факт конкуренции: будут высокие цены, будут редко заказывать :)
Да и технически там все оцифровано, диспетчеров целый штат, ip-телефония, все логируется, номера телефонов,явки, пароли,адреса — откуда, куда, когда (можно потом юзать историю поездок и заказывать такси без участия диспетчера) и пр.
Кстати, после того, как приняли заказ, приходит, как правило, три смс:
- инфа о заказе, с адресом и стоимостью поездки;
- смс о том, что заказ принят водителем — сообщают номер, марку и цвет машины;
- наконец — что машина подъехала.
P. S. В Екатеринбурге, к примеру, уже лет 5, наверно, как такая схема стандартом де-факто является… Для меня было неприятным сюрпризом, что в МО службы такси, которыми я пользовался в течение 2013-16 годов о такой системе даже не слышали.
Skreep
08.11.2016 19:50На заре своей IT-карьеры работал в одном стартере. Там был своеобразная бизнес-модель, решения изменялись в последний момент. Так вот там инвестор (он же гендир) постоянно удивлялся, как можно не уметь оценить точные сроки выполнения задач. Он сам из строительного бизнеса, и я ему привел пример. Представь, что ты должен уложить асфальт на пяти квадратных км. Все просто, считается элементарно. Но только асфальт нужно уложить на вертикальную, постоянно меняющуюся поверхность. А еще тебе не известен состав и поведение асфальта, потому что его изобрели позавчера. Техники, способной уложить асфальт вертикально, вообще не существует, ее нужно сперва изобрести. А на середине процесса ПМ, увидев, как сложно идет укладка, говорит «ну нафиг, давай горизонтально, но сорок км, а не пять». После этого тема точных сроков как-то поутихла.
Landgraph
08.11.2016 21:16-1Невыполнимых задач не бывает, есть только требующие значительного количества времени или другого ресурса (которого, естественно, в нужных объемах нет).
Руководитель/менеджер не хочет слышать «нет, невозможно», он обычно хочет видеть варианты (пусть даже укрупнённые), из которых он выбирает: хотите 5км вертикально? Нет проблем, за вертикальный асфальтоукладчик готов взяться Завод тяжелого машиностроения им.Кащенко, его создание займёт 10 лет, стоимость будет -надцать млрд, если всё ок — завтра приступаем, итого в 11 лет уложимся. А можем дёшево и сердито положить горизонтально, за неделю, ещё и в 8 раз больше.
Так и с ПО: получая задачу ты уже в голове (а лучше на листке) прикидываешь примерный объём работы, к концу совещания уже готов примерный план работ. Можно прикинуть сроки, лучше умножить на 2 или 3. Понятны задачи, что являются ключевыми, а на чём можно сэкономить и сделать после сдачи (а даже если не сделать — не критично).
Я одно время в одной интересной отрасли (не медицина, конечно, но попытка тоже даётся только одна) получал задачи класса «завтра едете туда-то, что делать — определяетесь на месте, задача должна быть выполнена». То, что нужна подготовка, предварительное обследование, планирование и прочее — никого не волнует… Две минуты на обдумывание, навскидку 2-3 возможных варианта исполнения, согласование одного из предложенных.
Партия сказала «Надо!», комсомол ответил «Есть!». Мотивируем сотрудников на выполнение невыполнимого. Приехали, обследовали, на месте принял/уточнил/согласовал решения, спланировали, развернулись, отработали, свернулись, уехали. Самое сложное для меня было так распределить и донести задачи, чтобы исполнители с ними справились. А самое страшное было то, что результат зависит ото всех: один накосячит — накроется работа всей команды. Но при этом я сам знаю всё, что должен сделать исполнитель и могу проверить/исправить его работу.
Но зато все довольны: и заказчик, и руководство, и непосредственные исполнители, т.к. выполнили «невыполнимое».
В этом был свой драйв =)
Вон, народ ставит ориентировочные сроки полёта на Марс, и стремится к ним! И даже если они просчитаются и отправятся на год позже — они всё равно отправятся на, мать его, Марс! А если сроки не ставить — работа не будет выполнена никогда.Skreep
08.11.2016 21:31Речь не о невыполнимых задачах, речь о том, что сроки не всегда можно назвать точно.
Landgraph
08.11.2016 22:11Так и я про время как ресурс. Нельзя сказать точно — берите укрупнённо. Нельзя укрупнённо — берите срок на расчёт.
Мне очень помогло научиться считать сроки на работе, где даты были независимы от нас. Не успели вовремя — вся работа в утиль, никаких «ещё пол часика и всё будет готово». И хочешь не хочешь — считаешь и своё время, и подчинённых, и подрядчиков…Skreep
08.11.2016 22:13Когда начальник не в теме, он не всегда понимает, что такое «укрупненные сроки».
Landgraph
08.11.2016 22:26Так укрупнённые они для Вас, а для него — просто сроки. Ему они нужны для принятия соответствующих решений: согласиться на них, добавить ресурсов, снизить требования, или ещё что-то.
Коллега, я так понимаю у Вас имеется опыт управленца, не поделитесь как Вы выходите из ситуации неопределённости сроков исполнителями?Skreep
08.11.2016 22:32Проблема «укрупненных сроков» а том, что они не соответствуют действительности. Да, это нормально, и применяется повсеместно. И один-два таких случая, чаще всего погоды не сделают. Но если их становится больше, планирование проекта стремится к чепухе, а менеджеры перестают контролировать процесс (это я специально утрировал, конечно).
Во-первых, я стараюсь максимально точно определить задачу, стек и сопутствующие обстоятельства. Это повышает точность прогнозов, что очевидно. Ну и руководству я всегда стараюсь честно сказать, что точных сроков не будет. Максимум — разброс «от»и «до». Но часто начальству нужно прям на пальцах объяснить, почему именно так.Landgraph
08.11.2016 22:50Ну так срок «до» — обычно и есть укрупнённый.
Срок «от» опасен тем, что часто предполагает как вариант «всё просто прошло гладко», так и отказ от некоторого функционала, либо пренебрежение проверками, тестами и прочую экономию. А верхнее звено логично предполагает, что результат «от» = результат «до». При чём в расчёт часто берётся только минимальный срок. А потом начинаются ночные работы, санкции за срыв сроков, обвинения во всём на свете и прочее…
Уж лучше выполнять пятилетку за три года и быть молодцом, чем за семь и быть врагом народа, разве нет?Skreep
08.11.2016 23:05Да, до — и есть укрупненный. Даже с небольшим запасом укрупненный.
Насчет пяилетки — конечно, лучше. Но ситуация, описанная Вами, очень частная, хотя и проявляется периодически. Видимо, меня любят боги, потому что за последние пару лет мне ни разу не попался руководитель, которому я не смог бы объяснить истинное положение дел. Картинками, жестами, пантомимой — но объяснял, что «от» — это «от», а «до» — это «до»))
Не все манагеры одинаково полезны.Landgraph
08.11.2016 23:27Диалог с руководителем о том, что в такой-то срок будет выполнен такой-то объём работ, а в такой-то — другой — это тоже обозначение сроков. Разве нет?
Skreep
08.11.2016 23:33Конечно. Я и не утверждал, что сроки не нужно обозначать, я говорил о том, что не всегда это можно сделать точно. И что руководителям надо объяснять, почему именно так, а не называть «укрупненные сроки» как единственно возможные, потому что это приводит к сбоям в планировании.
maxpsyhos
09.11.2016 07:47Нельзя сказать точно — берите укрупнённо.
Проблема в том, что «укрупнённо» с учётом всех возможных факапов часто получается вида «от 1 недели до 5 лет», причём чем опытнее разработчик, тем больше возможных факапов он видит. И чтобы оценка не уходила в бесконечность, приходится выводить некое мат-ожидание с учётом вероятности возникновения проблем. Но начальство как правило не особо углубляется в мат-анализ. Есть цифра — она будет поставлена в график, в лучшем случае не уменьшая оценки «паникёров-перестраховщиков».
Кроме того, срок может вообще не поддаваться расчёту. Что-то вроде:
— Когда закончишь интеграцию?
— Когда админ заказчика закончит настройку своей базы.
— Ты дату точную назови…
Ну то есть работает кто-то другой, а сроки требуют с тебя.Landgraph
09.11.2016 10:29Так что получается, что чем опытнее разработчик, тем сильнее он затягивает сроки? По идее опыт разработчика должен позволить ему максимально точно оценить сроки исполнения работы, а не написать сочинение на тему «Почему эту программу можно написать как за неделю, так и за 5 лет».
А теперь «правильный» вариант диалога:
— Когда закончишь интеграцию?
— Через три дня, после того, как админ заказчика закончит настройку своей базы.
— ОК, пойду пинать заказчика.
Вместо изначального f(x) = x(y), где переменная становится не определённой функцией, получается простая линейная функция f(x) = x + 3.maxpsyhos
09.11.2016 10:38Первое работает только в том случае, если у разработчика есть полная исчерпывающая информация о системе/системах, с которыми ему придётся работать, что есть сильно не всегда. Особенно весело, если по условиям документация может быть получена только ПОСЛЕ оценки, но это уже вообще клиника и встречается не часто.
Второе работает, только если руководство достаточно адекватное.Landgraph
09.11.2016 11:02Если информации нет, в чём проблема её запросить? Инициировать рабочее совещание для уточнения всех интересующих вопросов? Отсутствие постановки задачи или её некорректная постановка не приравнивается к невозможности определить сроки её выполнения.
Встречал и ситуацию с пост-предоставлением документации, плюс два месяца на изучение доков и переработку изначальной модели. И стоимость работ возрастает в два-три раза. И вот уже откуда-то «тайно» прилетает отсутствующая документация.
Настолько неадекватное руководство я ещё ни разу, к счастью, не встречал.
Landgraph
08.11.2016 20:18-2Да, жаль, что часто управленцем является человек слабо разбирающийся в разработке… А как в такой ситуации можно разбивать задачу и делегировать её части компетентным сотрудникам — вообще не представляю.
Хуже того, на переговорах с заказчиком такой управленец уверен, что создать дополнительное поле в таблице — это работа на пол-года, а вот определить, например, что на картинке изображена машинка или котег — чё там думать, результат будет уже завтра, это же элементарно!
Может в бизнес-аналитики/тимлиды податься? Как раз работу ищу =)
Резюме: Быстро нахожу общий язык с людьми. Синхронно перевожу с языка заказчика на язык исполнителя и обратно. Умею понять заказчика и донести до него позицию исполнителя. Что не может сделать конечный исполнитель — сделаю вместе с ним, заодно обучу.miksoft
08.11.2016 21:26Хуже того, на переговорах с заказчиком такой управленец уверен, что создать дополнительное поле в таблице — это работа на пол-года, а вот определить, например, что на картинке изображена машинка или котег — чё там думать, результат будет уже завтра, это же элементарно!
Причем это может внезапно оказаться именно так.
Например, у нас одно поле в учетной БД «создается» уже год или больше. Так долго потому, что на него многое завязано — под сотню сотрудников фирмы, десятки печатных форм, бизнес-процессы внутри фирмы, взаимодействие с контрагентами и т.п.
А картинку для распознавания, может быть, достаточно засунуть в какой-нибудь гугловый API для распознавания.Landgraph
08.11.2016 21:50Возможен и такой вариант, но, коллега, это уже далеко не «создание поля в БД», а некий многоступенчатый процесс, в составе которого имеется создание поля в БД, судя по описанию… А гугловый АПИ может не прикручиваться на режимном объекте, где нет инета, хотя на презентации всё было так сладко, даже через глючный Вай-Вай…
Именно поэтому управленец, принимающий решения, должен быть в курсе того, как и что будет реализовано, чтобы не подставлять себя, свою команду и организацию.
n0dwis
09.11.2016 08:59Не до конца первый пункт осветили. Упустили самую раздражающую ситуацию — когда ты по уши в очередной задаче, досконально вник в ТЗ, жонглируешь в уме десятком классов, и тут — «Глянь, тут, вроде, немного. Или хотя-бы скажи, насколько сложно.».
Chamie
15.11.2016 17:29+4Известная картинка
dsdred
09.11.2016 10:09Случаи из жизни которые часто привожу в пример как не надо ставить задачу:
1) Приходит письмо с темой. Нужно сделать отчет, см. вложенный файл
Открываем файл там название колонок и все…
2) У нас есть конфигурация на 8.1, ее нам 4-5 лет назад делал франч, нужно в УПП сделать тоже самое только ЛУЧШЕ!
Самые раздражающие фразы.
1) Все должно быть автоматически
2)
-Надо чтобы это само грузилось и заполнялось.
-Хорошо, откуда брать данные?
-Не знаю. придумайте что нибудь?
Грабли для новичков:
-Почему это так работает?
-Вы сами это просили так сделать!
-Я не мог такое попросить!!!
Поэтому просите пожелание в письменной форме а то потом не докажешь.
А философия про искусственный интеллект из уст менеджеров уже просто не раздражает, а бесит.
excoder
09.11.2016 10:10+2Вообще, представление клиентов о работе отлично отражает старое, но не теряющее актуальности видео про 7 красных перпендикулярных линий, некоторые из которых должны быть нарисованы зелеными чернилами, а некоторые — прозрачными.
Дело в том, что видео про эксперта высмеивает именно эксперта, а не клиента. Одно из возможных решений:
Нет ничего хуже для программиста, чем узость и однобокость мышления.maxpsyhos
09.11.2016 10:45+3Это костыль, который получается три игнорировании того, что понятия «параллельность» и «перпендикулярность» чётко определены и применимы только для определённого типа объектов — прямых.
Нет ничего хуже для программиста, чем креативные гуманитарии, искажающие общепринятую терминологию.excoder
09.11.2016 12:32Они платят деньги. Программист не работает за идейно чистые решения, которые никому не нужны.
maxpsyhos
09.11.2016 12:49+1Тут вопрос не в идейной чистоте, а в том, что заказчик с исполнителем изначально говорят на разных языках.
На том языке, на котором говорит программист:
— эти линии не параллельные и не перпендикулярные, потому что не прямые
— заливка цветом и текстурой — это разные операции
То есть в его терминологии задача не выполнена.
Pakos
09.11.2016 15:55-1А нужны ли решения, не решающие поставленную задачу?
excoder
09.11.2016 23:59+1Нет. Заказчик имеет некоторую конкретную проблему, которая решаема в некотором пространстве решений, которое ему априори неизвестно. Он готов платить за решение. Поскольку это пространство ему неизвестно, он формулирует задачу некорректно, косноязычно и т.д. Эксперт знает пространство решений, но не знает проблемы заказчика. Задача эксперта, в первую очередь — осознать проблему. Это задача переговоров, коммуникации и перевода. Но эксперту такая трансляция должна быть по зубам — ведь он знает всё пространство, и поэтому обозревает целое семейство возможных проблем.
В формулировке из текущего обсуждения складывается ощущение, что эксперт — это такой педант, который даже не должен разговаривать с заказчиком, который не может сформулировать ему проблему. Потому он говорит, что решение невозможно, не желая признавать, что заказчик не владеет пространством решений. «Fuck you, that's why» эксперт. Конечно, если заказчик продолжает настаивать на своей формулировке, которая не даёт эксперту возможности указать решаемую проблему в пространстве решений, «на лад их дело не пойдёт» и контракт не состоится.
Landgraph
09.11.2016 10:50+3Ценность «эксперта» не в том, чтобы с умным видом доказать, что все вокруг дураки и несут чушь, а в том, чтобы максимально эффективно решить поставленную задачу, даже если условия звучат по-дурацки.
dsdred
09.11.2016 11:11Звучит примерно так:
-На, что жалуетесь?
-Доктор, надо ампутировать ему ногу.
-Как скажите!
И чтобы уж наверняка, ампутируем и левую и правую.
А далее вопрос:
-Доктор, а почему он не ходит?fireSparrow
09.11.2016 11:16+8Вспоминается анекдот:
— Доктор, отрежьте мне член, очень надо!
— На хорошо, раз надо — отрежу.
После операции. Доктор:
— А скажите, зачем вам вообще это было нужно?
— Ну просто понимаете, я женюсь на еврейке, а у них такая традиция.
— Так может быть, вам нужно было сделать обрезание?
— Ну да. А я как сказал?
user343
11.11.2016 20:32Память у вас плохая, в заказе была ошибка всего на 1 букву — «сделайте мне ОТрезание».
Письменный контракт нужен был перед операцией, тогда доктор выживет :)polifill
12.11.2016 12:01Я слышал в интерпретации — «кастрируйте».
Человек незнамомую ему терминологию перепутал «кастрация» и «обрезание» — имхо, в моей версии анекдот более тоньше звучит.
fireSparrow
09.11.2016 11:20+1Тут просто чистого технаря без опыта общения с живым клиентом притащили на совещание.
Если человек действительно ценный специалист в своей области, но не умеет общаться с клиентом, то между специалистом и заказчиком всегда должен быть технически грамотный менеджер, который выяснит потребности заказчика и поможет ему составить адекватное ТЗ. По которому уже и будет работать специалист.
fireSparrow
09.11.2016 11:27+3А теперь уберите с этой картинки надпись и покажите её человеку, который не видел ролика.
После чего спросите его:
1. Являются ли все семь линий красными?
2. Являются ли 2-я, 4-я и 6-я линии прозрачными?
Если заказчик употребляет вполне конкретные понятия, которые с технической точки зрения противоречат друг другу и здравому смыслу, то нужно не выискивать лазейки, чтобы свести всё в непротиворечивую, но бессмысленную систему. Нужно вместе с заказчиком вернуться к его потребностям и целям, к конкретной предметной области, с которой он работает и в рамках всего этого выработать новое ТЗ. В идеале, по крайней мере, именно это и делает настоящий эксперт.
user343
10.11.2016 12:51+1Отличная картинка, долго рисовали?
А ко мне такие идеи пришли:
«По-видимому, здесь не умели делать движущихся объёмных фотографий» — из фантастической книжки, где полицейские аграрной планеты «офигели» от плоского удостоверения личности космонавта.
Это ж логическое продолжение усложнения картинки с развитием техники:
1) чёрно-белое фото в документах
2) цветное
3) голограмма/видео
Следовательно задача про 7 линий может быть решена и в динамике — как анимированный GIF или переключающиеся световые гирлянды на вывеске.
Можно придумать логотип компании, который «переливается» в зависимости от угла обзора, тогда и «волки сыты» (дезигнерши довольны) и аксиомы 2D геометрии выстоят.
Ещё вспомнилось:
«В процессе решения вопросов специалист для начальства виноват четырехкратно:
1. Он вообще открыл рот.
2. Нагло остался при своем мнении.
3. Своевременно на нем не настоял.
4. Оказался прав.»
:)
Sykoku
10.11.2016 15:20Ну, если так подходить к вопросу…
https://habrastorage.org/files/c0e/ea6/930/c0eea693023a40be86b79f1a44c51026.jpguser343
10.11.2016 17:28Развёрнутее бывают случаи. Техподдержка тут порадовала:
https://habrastorage.org/files/002/a29/bbb/002a29bbb5a140ec8eec8eda2b3c5c9c.jpg
И подобная статья была уже (перевод):
Реальная оценка или почему наступают дедлайны?
https://habrahabr.ru/company/ruswizards/blog/151029/
ShakaL-J-Peg-Script
09.11.2016 11:07Это все фигня, мне вон задание трех-дневное дают и говорят — «Ой мы тыт вспомнили, что у нас презентация, там работы на два часа, время пошло». Долбаная Худик.
CTAPOBEP
09.11.2016 11:07Сталкивался практически со всем из описанного (с разной степенью 'тяжести'), причем даже от менеджеров, у которых профильное образование было связано с программированием. А мое любимое — «Давайте писать код без ошибок».
Dementor
09.11.2016 15:00+1А вы руководили программистами? Нанимали ли для вас HR талантливых студентов-гениев? Вы просто не понимаете, что когда вам приносят код и говорят «зуб даю — все сделано и проверено», а он даже не компилируется, или компилируется, но при попытке хоть что-либо сделать выдает деление на ноль, или в поля на формах забыли прописать обработчики событий..., то «Давайте писать код без ошибок» — это единственные звуки, которые можно услышать после запикивания всех матов.
CTAPOBEP
10.11.2016 23:36Если Вы считаете, что Ваша работа сродни работе надсмотрщика за рабами, который ходит по рядам, щелкает хлыстом и выслушивает клятвенные заверения в том, что все в порядке, то ничего другого и не ждите. На самом же деле, Ваша работа заключается в создании (и непрерывном поддержании) такого процесса разработки, в результате следования которому (заведомо!) не идеальные люди будут выдавать результат требуемого качества. TDD и ревью кода в помощь.
Dementor
11.11.2016 00:03Мы говорим на разных языках. Это Ваша работа «щелкать хлыстом и выслушивать клятвенные заверения», а так же применять «TDD и ревью кода». Я обычный программист и моя работа — писать качественный код. Иногда у меня на все не хватает времени и мне берут помощников. Так вот качество работ обычно ниже плинтуса. И не важно кого мне набирают 1С программистов для бизнес-решений или интерфейсной части, С++ программистов для написания утилит, JS-программистов и дизайнеров для создания веб-решений — единицы что-то пытаются делать качественно и проверяют свой код, но все остальные даже минимальные тесты не делают. Мне нужно пересматривать работы за всеми и десятки раз отдавать на переделки.
Никто не требует от них интегрального тестирования (его делал я, а еще у нас были бетта-тестеры). Есть ТЗ — написать функцию, которая принимает четко описанные типы параметров и выдает четко описанный результат. Почему нельзя прочитать и сделать дословно? Почему не хватает параметров? Почему результат неправильного типа? Почему нельзя сделать элементарные проверки на ноль при делении или хотя бы набросать try/catch?
Боже, про какое TDD (разработку через тестирование) вы говорите, если люди элементарно пушат коммиты с неработающим кодом (опечатки в вызовах функций, потерянные кавычки и так далее), который вообще не компилится и в IDE светит красным??? Но при этом их в выполненной работе ничего не смущает.
olekl
09.11.2016 11:39+2Однажды когда со стороны заказчика в ответ на эстимейты прозвучало «как неделя? да я сам это за полдня сделаю», ответили «ок, давай, делай». Через неделю прозвучало «ладно, берите, делайте» :)
kolemik
09.11.2016 13:52+1«Вывести» в данном контексте выглядит как: «Вы должны по-капле выдавливать из себя программиста.»
stokker
10.11.2016 02:29-1Странная статья, где сталкивают лбом бизнес и программирование. Для решения этой ситуации нужен отдельный человек, разбирающийся в обеих сферах. Жизнь проста, если не усложнять…
gskm
10.11.2016 11:17Еще бесит, например, когда программиста принимают за электрика. У нас в организации все считают, что программисты знают на сколько выключили свет, что программисты должны чинить чайники и кофеварки. Я уже не говорю про работу грузчиками (выжемужчины, значит обязаны).
Oxoron
10.11.2016 11:42Последнее относится скорее к полу, нежели профессии. И потом, что мешает вам вежливо послать подобного коллегу? Или вы в Корпорации Зла работаете?
gskm
10.11.2016 12:09В филиале корпорации зла на земле :) Конечно вежливо объясняю, что это не входит в мои обязанности, но каждый раз все повторяется снова и снова. И дело тут не в способности послать или нет, а отношении и как это бесит.
user343
10.11.2016 17:43+1Относитесь как к безплатному фитнесу или отвечайте, что 1-го человека мало. Доказательства:
«1) Сколько программистов баз данных требуется, чтобы заменить перегоревшую E27 лампочку?
— Трое. Один напишет программу удаления лампочки, другой — вкручивания лампочки, а третий будет исполнять роль администратора патрона и проследит, чтобы никто не попытался ввинтить лампочку в то же место.
2) — Сколько нужно сотрудников службы поддержки компании MicroSoft, чтобы заменить лампочку?
— Четыре.
Первый — чтобы узнать регистрационный номер лампочки.
Второй — чтобы спросить: «А вы перезагрузиться пробовали?» (Выключатель включить/выключить.) Третий — чтобы спросить: «А вы пробовали ее переустановить?»
И четвертый, чтобы сказать: «Это у вас что-то с «железом». У нас в офисе лампочка работает отлично!»vikarti
12.11.2016 13:25по 1)… потому что по факту — эти трое решали задачу создания системы замены лампочек во всем городе
по 2) пока — да. смешно. а в будущем?
когда по регистрационному номеру можно провести удаленную диагностику лампочки с поддержкой IoT (или просто проверить что на конкретной серии лампочек — уязвимая прошивка и возможно стоит обновить прошивку)(статья про PoC вируса для реальных лампочек на ГТ была — https://geektimes.ru/post/282250/ )…user343
13.11.2016 01:29Для IoT и вообще технич. прогресса есть и физические ограничения:
1) электромагнитный смог как взаимоглушение связи между «умными» устройствами: https://geektimes.ru/company/asus/blog/265998/
2) окончание промышленных и редкоземельных металлов вместе с дешёвой энергией.
«Кожаные биороботы» при этом выиграют у неорганических.
3) «бесконтрольный рост энергопотребления для любой цивилизации означает самоубийство. Очевидно, что энергия и информация — не все, в чем нуждается цивилизация для успешного продвижения по шкале прогресса. Нужна новая шкала, которая принимала бы во внимание эффективность, паразитное тепло и загрязнение окружающей среды. Такая шкала разработана, и основывается она на концепции энтропии.»
«если ради производства информации цивилизация будет вырубать леса и громоздить горы бумажных отходов, она окажется погребенной под собственным информационным мусором.»
Источник: https://horseman5th.wordpress.com/2014/02/17/%d1%8d%d0%bd%d1%82%d1%80%d0%be%d0%bf%d0%b8%d1%8f-%d0%b8-%d1%82%d0%b5%d0%bf%d0%bb%d0%be%d0%b2%d0%b0%d1%8f-%d1%81%d0%bc%d0%b5%d1%80%d1%82%d1%8c/#more-1908
eSKon
15.11.2016 19:58Хоть раздел «ты должен мыслить как клиент» и проиллюстрирован забавным роликом, мысль на самом деле очень дельная и полезная. Программистам неплохо бы иногда задумываться, что программы пишутся для конечного пользователя. А то иногда выходит, что в ответ на замечание о баге слышишь подробную инструкцию, что пользователь должен проделать, чтобы обойти баг. Вот это неправильно.
NeverIn
16.11.2016 17:39«Правильный» менеджер… неужели в IT менеджеры настолько далеки от IT, что не могут оценить сложность задачи ?!
il--ya
18.11.2016 05:57Статья привлекла двусмысленным заголовком. Разочарован, что это случайность.
«Как вывести из себя программиста» вызывает аллюзии к чеховскому
… напишите, как этот молодой человек выдавливает из себя по каплям
программистараба и как он, проснувшись в одно прекрасное утро, чувствует, что в его жилах течёт уже не рабская кровь, а настоящая человеческая.
Программистам иногда тоже не мешает сделать над собой усилие, и попытаться понять, как работатают и мыслят люди, с кем они «работают бок о бок». Вывести из себя «программиста». По каплям.
A-Stahl
>«Нужно кое-что глянуть. Это быстро и несложно»
Сам смотри, морда канцелярская. Это же быстро и несложно.
>Ты так долго писал код, в нем же больше нет ошибок?
Я код писал, а не ошибки выгребал. Вали к тестировщикам. Тьфу…
>Ты должен мыслить как клиент
Должен?! Серьёзно? Я думал, что «мыслить как клиент» — твоя работа!
>Ты не должен отвлекаться — иначе ничего не получится
Так не отвлекай меня! Вали кофе пить или чем там менеджеры занимаются…
>Скажи точно, когда закончишь
Я закончу точно тогда, когда всё будет готово. И ни секундой раньше.
>Хватит тестировать, пора запускать
У тебя есть полномочия такое говорить? Есть? Ну ок. Мне, что, жалко что ли? Всё равно тестирование это не моя работа.
xxvy
У вас
ус отклеилсяглаз дёргается…GetShuk
И не только у автора.
Portnov
И не только глаз.
polifill
Вы — программист, которые не отвечает за свой код?
Что-то постоянно открешиваетесь от тестирования.
Хотя бы TDD программист должен делать сам, счита.
BDD — возможно и нет.
Solexid
Все конечно супер, но как обычно все утыкается что никто не захочет даже пытаться переучиваться, может от силы пара тысяч человек, просто just4fun. Или есть какие то исследования которые говорят об обратном?
polifill
В мире давно уже все делают все
https://habrahabr.ru/company/jugru/blog/314644/
«о главных принципах DevOps. Помогайте друг другу, что ли...»
А автор того коммента — открещивается только.
Живет в каком-то прошлом веке — я программист и QA не моя задача.
Его слова — это не слова не профи, а слова профана.
«В чем же принципиальное отличие DevOps подхода от стандартного подхода в QA?
– Из моей собственной практики — в DevOps подходе люди начинают больше писать интеграционных тестов, сокращают циклы разработки. Continuous Delivery — вполне естественный процесс доставки изменений в DevOps среде, а это косвенно улучшает ситуацию для QA, уменьшая количество изменений в билдах, которые ему требуется протестировать. Конечно, ценой увеличения количества этих самых билдов, но тут уже вопрос баланса.»
"– Чаще всего в DevOps используется Continuous Delivery, для которого характерен быстрый темп выкатывания новых релизов и деплоя. Не превращается ли это в итоге в «крысиные бега», когда один человек занимается и написанием кода, и тестированием, и административными функциями?
– Ну, если Вы у себя в команде нанимаете «DevOps-инженера» — то превращается. До тех пор, пока DevOps будут связывать с конкретными людьми — то ситуация будет выглядеть примерно так, ведь спрос будет идти с этих конкретных людей. А вот когда у вас уже команда «пропиталась» DevOps-ом — то выкатыванием занимаются все вместе. Ведь, напоминаю, работа разработчика не заканчивается коммитом, она там только начинается. Довести свои изменения до конечного пользователя — вот это цель каждого. "
В июне 2016 года на сайте devops.com вышла статья «How DevOps is Killing QA», в которой говорится, что DevOps не нуждается в QA.
Dayver
Удалите у себя из головы фразу «Ты ж программист»… или мне может еще и самому нарисовать эту кнопку? а ну да и протестировать же тоже обязан… может еще и чайник отремонтировать? — ну да «Я ж программист»
EugeniaPanasova
Переключение раскладки, числовая и управление — под большими пальцами.
Или вы другое имели в виду?
R_o_u_n_d
… краткая постановка задачи менеджером