Комментарии 87
Нельзя просто взять и сказать «просто сделай» boromir.jpg
«Просто найди автозаменой и замени это на сервере».
«Ок, кэп!»
Перезаписал права на файлы (на тот момент вообще не знал об этом), релиз наутро, сервер не работает.
«Ок, кэп!»
Перезаписал права на файлы (на тот момент вообще не знал об этом), релиз наутро, сервер не работает.
Иногда некоторые говорят — «Нужно запрограммировать простую программу. Это очень просто и быстро, для профи на 5 минут»
Обычно после общения с таким клиентом выясняется, что денег тоже «просто» — просто нет.
Обычно после общения с таким клиентом выясняется, что денег тоже «просто» — просто нет.
Просто вода.
Не читал статью, но не согласен! Можно «просто» добавить кнопку «Избранное» с права от элемента если верстатель/js кодер не туг и происходит разработка MVP.
В данном контексте «просто» автоматически подразумевает, что ты конечно прекрасно понимаешь, что будет происходить по нажатию на этой кнопке, как она будет называться и выглядеть, как органично вольётся в дизайн и не порвёт вёрстку. А ещё само собой разумеется магическим образом в личном кабинете появится новый раздел с «избранным», который будет выводить список этого избранного. И в базе данных сама, как по щучьему велению создаст себя таблица, в коде будет прописана соответствующая модель, будут прописаны необходимые зависимости и вот это вот всё ведь и правда просто какая-то маленькая кнопочка, смотри, тебе тут работы на полчаса.
Как 4 часа? Да ты что, мы дольше об этом говорим, ты бы уже всё сделал!
Как 4 часа? Да ты что, мы дольше об этом говорим, ты бы уже всё сделал!
Разумеется, если верстальщик не туг, он легко изменит существующий дизайн и впишет в него кнопку «избранное» так, чтобы она в нём нормально выглядела. Не составит ни малейшего труда сделать эту работу в трех версиях: для настольного ПК, планшета и мобильника. Ну и само собой, программирование этой кнопки — тоже проще пареной репы, даже когда она завязана на бэкэнд. Всё просто, что может быть ещё проще. Как тут ниже писали «для профессионала работы на 5 минут» — классика!
Хм. Добавить можно, а вот сделать чтобы работала — уже не так просто :)
"Просто" ПМы могут употреблять, чтобы заранее занизить оценку которую ждут от разработчика.
Когда слышишь "просто..." психологически сложно дать оценку в несколько часов на эту задачу.
А еще часто приходится употреблять такое, чтобы обозначить реальные рамки. Чтобы заранее обозначить "в случае сложно — не надо".
Например, задаю вопрос — "можем ли мы просто сдвинуть?", который может по недосмотру прозвучать как утверждение ("давай просто подвинем"), но дефолт-контекст — любое предложение PM — это приглашение к обсуждению.
В оригинальной статье, кстати, используется слово Just, которое в данном случае можно было бы перевести и как "всего-лишь". Вот такое в утвердительном тоне может означать излишнюю уверенность командующего, это правда.
Увы, но порой речь идет о двух разных вещах.
Первая — банальной некомпетентность. Как руководителей так и разработчиков. Если вам говорят «Просто размести это где-нибудь на сервере» и вы не можете этого сделать, то вам не место в профессии.
Если у вас нет доступа, попросите. Если вы технически не знаете, как это сделать, погуглите, вы же не дебил, правда?
Увы, но проблема ведь в том, что разработчики не хотят/не умеют разговаривать с руководителями. Умение общаться с людьми такой же навык, как и все остальные.
Вторая — скрытая сложность. Это намного более серьезная проблема, которая лежит в области прогнозирования рисков в разработке. На любую работу всегда закладывается время с запасом на непредвиденные трудности. Одна из таких — скрытая сложность, которая обычно выливается в технический долг.
Опять же в данном случае это вопрос компетентности руководителя проекта и знания проекта разработчиками, умения давать габаритную оценку.
Первая — банальной некомпетентность. Как руководителей так и разработчиков. Если вам говорят «Просто размести это где-нибудь на сервере» и вы не можете этого сделать, то вам не место в профессии.
Если у вас нет доступа, попросите. Если вы технически не знаете, как это сделать, погуглите, вы же не дебил, правда?
Увы, но проблема ведь в том, что разработчики не хотят/не умеют разговаривать с руководителями. Умение общаться с людьми такой же навык, как и все остальные.
Вторая — скрытая сложность. Это намного более серьезная проблема, которая лежит в области прогнозирования рисков в разработке. На любую работу всегда закладывается время с запасом на непредвиденные трудности. Одна из таких — скрытая сложность, которая обычно выливается в технический долг.
Опять же в данном случае это вопрос компетентности руководителя проекта и знания проекта разработчиками, умения давать габаритную оценку.
Увы, но проблема ведь в том, что разработчики не хотят/не умеют разговаривать с руководителями. Умение общаться с людьми такой же навык, как и все остальные.
Желание и умение со стороны разработчика, должно дополняться таким же желанием со стороны руководителя/пользователя.
В реальности же часто бывает, что на 10 аргументированных доводов, почему так нельзя делать, тебе в отвечают банальным «Что ты мне тут мозги
Если руководитель некомпетентен, то он не должен занимать свою должность.
Из вашего примера руководитель ведет себя в высшей степени непрофессионально. У вас два пути — разговаривать с начальством более высокого уровня (если оно есть) или менять работу.
Из вашего примера руководитель ведет себя в высшей степени непрофессионально. У вас два пути — разговаривать с начальством более высокого уровня (если оно есть) или менять работу.
Руководитель видит, что для бизнеса «надо», чтобы бизнес работал и зарабатывал.
ИТ-шник получает деньги от того, что бизнес работает.
Где вы тут увидели некомпетентность руководителя?
Имхо, здесь как раз некомпетентность ИТ-шника.
ИТ-шника вообще-то наняли, как раз потому, что он является профессионалом в своей сфере и он и должен донести до прочих (руководителя, пользователя), как правильно сделать.
ИТ-шник получает деньги от того, что бизнес работает.
Где вы тут увидели некомпетентность руководителя?
Имхо, здесь как раз некомпетентность ИТ-шника.
ИТ-шника вообще-то наняли, как раз потому, что он является профессионалом в своей сфере и он и должен донести до прочих (руководителя, пользователя), как правильно сделать.
Даже когда пользователь требует большую зелёную кнопку «Сделать хорошо» или 7 перпендикулярно-параллельных линий?
Вам видимо не приходилось объяснять людям, почему их хотелку вообще нельзя сделать, т.к. она сформулирована в духе «хочу круглый квадрат» или сделать можно, но не за один день. При этом пользователь спрашивает, почему это нельзя сделать быстро, ты ему объясняешь и расписываешь всё по пунктам, а в ответ: «Я не понимаю, почему так нельзя!» При этом пользователь не понимает не потому что ты ему плохо объяснил, а потому что он не хочет понять.
Вам видимо не приходилось объяснять людям, почему их хотелку вообще нельзя сделать, т.к. она сформулирована в духе «хочу круглый квадрат» или сделать можно, но не за один день. При этом пользователь спрашивает, почему это нельзя сделать быстро, ты ему объясняешь и расписываешь всё по пунктам, а в ответ: «Я не понимаю, почему так нельзя!» При этом пользователь не понимает не потому что ты ему плохо объяснил, а потому что он не хочет понять.
Хорошая отмазка — виноват не я а руководитель.
Это одно из моих основных занятий.
После того как люди узнают СКОЛЬКО стоит круглый квадрат сделать за 1 день — они сразу становятся сговорчевее. И выясняется, что нужно не за 1 день, а за полгода и не круглый, а как программисту удобнее. Да и вообще не квадрат, а прямоугольник произвольный.
Говорят в конце концов так: «сделай тот вариант, что технически дешевле, проще и быстрее для тебя».
Человек, который не умеет беседовать по задаче — так всю жизнь и будет получать типовое задание в виде «круглый квадрат за 1 день», да еще и за зарплату маленькую.
ВЫ СПЕЦИАЛИСТ.
Вас наняли чтобы вы как человек ЗНАЮЩИЙ ИТ — помогали руководителю РАЗОБРАТЬСЯ.
А не сталовились в позу.
Не брались за выполнения задач про квадрат круглый.
Вам видимо не приходилось объяснять людям, почему их хотелку вообще нельзя сделать
Это одно из моих основных занятий.
После того как люди узнают СКОЛЬКО стоит круглый квадрат сделать за 1 день — они сразу становятся сговорчевее. И выясняется, что нужно не за 1 день, а за полгода и не круглый, а как программисту удобнее. Да и вообще не квадрат, а прямоугольник произвольный.
Говорят в конце концов так: «сделай тот вариант, что технически дешевле, проще и быстрее для тебя».
Человек, который не умеет беседовать по задаче — так всю жизнь и будет получать типовое задание в виде «круглый квадрат за 1 день», да еще и за зарплату маленькую.
ВЫ СПЕЦИАЛИСТ.
Вас наняли чтобы вы как человек ЗНАЮЩИЙ ИТ — помогали руководителю РАЗОБРАТЬСЯ.
А не сталовились в позу.
Не брались за выполнения задач про квадрат круглый.
Если вы не заметили, я писал не о руководителе разработчика, а о пользователе.
По-вашему является некомпетентностью разработчика, когда:
1. Бизнес-заказчик не понимает и не хочет понимать свои же процессы, а только хочет, чтобы оно работало?
2. Не хочет прочитать документ из 8 страниц с картинками, где описано как теперь будет происходить работа. При этом оправдывает это тем, что у него нет времени… за полтора месяца времени не нашли, ага.
3. Хочет, чтобы строился отчёт на основании двух документов, которые никак между собой не связаны. При этом, когда ему говоришь, что их нельзя соотнести между собой, т.к. у них из общего только клиент, а вязать нужно по договору, которых может быть много у клиента, заказчик сам упирается рогом и продолжает требовать.
4. и так далее и тому подобное
По-вашему всегда виноват сотрудник ИТ? Сотрудники бизнеса не должны уметь беседовать о задаче?
По-вашему является некомпетентностью разработчика, когда:
1. Бизнес-заказчик не понимает и не хочет понимать свои же процессы, а только хочет, чтобы оно работало?
2. Не хочет прочитать документ из 8 страниц с картинками, где описано как теперь будет происходить работа. При этом оправдывает это тем, что у него нет времени… за полтора месяца времени не нашли, ага.
3. Хочет, чтобы строился отчёт на основании двух документов, которые никак между собой не связаны. При этом, когда ему говоришь, что их нельзя соотнести между собой, т.к. у них из общего только клиент, а вязать нужно по договору, которых может быть много у клиента, заказчик сам упирается рогом и продолжает требовать.
4. и так далее и тому подобное
Человек, который не умеет беседовать по задаче
По-вашему всегда виноват сотрудник ИТ? Сотрудники бизнеса не должны уметь беседовать о задаче?
По-вашему всегда виноват сотрудник ИТ? Сотрудники бизнеса не должны уметь беседовать о задаче?
Представьте себе вы делаете ремонт своей квартиры.
Существуют, оказываетеся краски разных видов. Дорогие краски — идут для покраски потолка, так как они растекаться должны лучше. На стены же можно подешевле.
Ну и представьте, что маляры вам этого не объяснили.
Вы купили и для стен и для потолка одинаковую краску — подешевле, разумеется.
Какая тут может быть ваша вина или ваше неумение беседовать?
Вам же И В ГОЛОВУ ДАЖЕ НЕ ПРИШЛО БЫ спросить такие вещи, потому как вы не специалист в этой сфере.
Да, в сугубо технических делах виноват технический специалист. В нашем случае это будет ИТ-шник.
А вина управленца в некорретном решении других вопросов:
- приоритетов задач (что раньше, что потом делать, если нет технической зависимости по порядку выполнения. Если техническая зависимость есть между пунктами — то решать это дело технического специалиста)
- оценок целесообразно ли столько ресурсов положить на выполнение задачи, окупит задача себя в бизнесе
А теперь представим по-другому
Я: Нужно, чтобы вы покрасили до завтра (то есть за 1 день).
Маляры: Нет, это невозможно. Нужен день на грунтование, ещё день на покраску и пару дней на высыхание. Минимум 5 дней.
Я: Я всё-таки не понимаю, почему нельзя.
Как с такими Я разговаривать?
Я: Нужно, чтобы вы покрасили до завтра (то есть за 1 день).
Маляры: Нет, это невозможно. Нужен день на грунтование, ещё день на покраску и пару дней на высыхание. Минимум 5 дней.
Я: Я всё-таки не понимаю, почему нельзя.
Как с такими Я разговаривать?
Маляры: Нет, это невозможно. Нужен день на грунтование, ещё день на покраску и пару дней на высыхание. Минимум 5 дней.
Я: Я всё-таки не понимаю, почему нельзя.
Здесь легко и просто как раз — тут исполнителю следует предложить заказчику варианты (и вилку цен и сроков заодно):
1) Сделать как положено. Много времени. Дорого. Будет хорошо держаться.
2) Сделать быстро, не как следует. Объяснить в чем минусы (держаться будет плохо, ложиться краска будет неровно) — это обязательно нужно сделать.
Я тут тоже не понимаю а в чем проблема то?
Мало ли какие у заказчика соображения? Может у него жена послезавтра возвращается (с отдыха, из роддома, из больницы, от родителей) и пр. И ему просто негде жить с женой.
Ну или все время пока шел ремонт он жил в гостинице, а тут деньги кончились. Или жил у друзей пока шел ремонт, но достал их и они уже вещи заказчика выставили за порог.
Мало ли что там у него.
Короче, это вообще не ваше дело из каких соображений заказчик может потребовать радикального ускорения и нарушения технологии работ.
Ваше дело:
Объяснить в чем минусы и плюсы различных решений и предоставить выбор заказчику между озвучанными вами вариантами.
Бизнес-заказчик не понимает и не хочет понимать свои же процессы, а только хочет, чтобы оно работало?
Если вы системный аналитик, как раз и занимающийся выяснением что там где и как в бизнес-процессах, то имейте ввиду, что деньги вам платят именно за то, чтобы вы таки выяснили у заказчика.
Вы должны клещами из него вытянуть. Пытать. Умолять. Угрожать. Бить. Бухать вместе. Как угодно. Но составить ТЗ. В этом и заключается ваша работа.
Если же вы ожидаете, что заказчик даст вам готовое и хорошо сформулированное ТЗ — то спрашивается зачем вам платить такие деньги, даже не так, зачем вам вообще как специалисту, за которого работу сделал клиент (заказчик) вообще хоть копеечку платить?
Другой вариант:
Клиент (заказчик) предоставляет вам на откуп все вопросы по бизнес-процессам. Не желает вдаваться в детали. Не желает, как вы написали, с бизнес-процессами своими разбираться.
Никаких проблем нет:
- Зафиксируйте грубо границы желаемого заказчиком.
- Заложите в стоимость вашей работы разбирательство в бизнес-процессах заказчика.
- Возьмите предоплату, подпишите договор, акт — сделайте все, чтобы заказчик не слился, когда вы уже проделайте кучу работы. Ну или хотя бы чтобы предоплата вам осталась.
Я рассуждаю, как разработчик, работающий с внутренними заказчиками, когда нет бизнес-аналитика
Я рассуждаю, как разработчик, работающий с внутренними заказчиками, когда нет бизнес-аналитика
Это неважно.
Значит функции аналитика выполняете вы.
И ваша задача:
Любым способом выбить у внутреннего заказчика — а что ему надо.
Хотите — пытайте, хотите — шоколадку подарите.
Как угодно — но выяснить.
Очень частно внутренние заказчики озвучавают только цели.
А сам процесс, который нужно будет под эти цели — не озвучивается.
Не вижу с этим никаких проблем.
Единственное, что вам еще будет нужно
так это подойти к руководителю (предприятия, подразделения) и согласовать вопросы по этим изменению этих процессов, по выделению ресурсов и перераспределению обязанностей сотрудника.
Пример:
Вам ставят задачу «Внедрить штрик-сканеры на складе при выдаче товаров».
Вы это переваривайте и выдаете руководству что нужно для этого сделать:
1) Купить компьютеры. Очистить столы кладовщиков, чтобы можно было поставить туда компьютеры. Кому то вообще столы заменить на новые, так как компьютер не влазит.
2) Добавить штрих-код в накладные, чтобы было можно быстро находить накладную
3) Создать для кладовщиков специальный узкоспециализированный интерфейс пользовательский, в котором они ничего кроме сканирования делать не смогут.
4) Просканировать все товары. Если у кого нет штрих кодов — напечатать. Выделить для этого отдельное рабочее место (компьютер, стол и место под товары, которые будут подноситься).
5) Купить специальный принтер для печати штрих-кодов на ленте с липкими этикетками.
Ну а кто по вашему должен это придумать был?
Сами кладовщики?
Они понятия не имеют о таких вещах.
Скорее всего этим будет заниматься коллегиально команда: сисадмин, программист, руководитель, начальник склада.
>Хорошая отмазка — виноват не я а руководитель.
Это всегда так, бывает что руководитель виноват потому что нанял такого работника, но все равно, виноват руководитель.
>Вас наняли чтобы вы как человек ЗНАЮЩИЙ ИТ — помогали руководителю РАЗОБРАТЬСЯ.
Очень сомнительное утверждение, есть кодеры, есть программисты, есть ПМы и есть постановщики задач, и не стоит смешивать их в кучу.
К примеру, если постановщик утвердил задачу, то в 80% контор программисту придется делать круглый квадрат.
Это всегда так, бывает что руководитель виноват потому что нанял такого работника, но все равно, виноват руководитель.
>Вас наняли чтобы вы как человек ЗНАЮЩИЙ ИТ — помогали руководителю РАЗОБРАТЬСЯ.
Очень сомнительное утверждение, есть кодеры, есть программисты, есть ПМы и есть постановщики задач, и не стоит смешивать их в кучу.
К примеру, если постановщик утвердил задачу, то в 80% контор программисту придется делать круглый квадрат.
К примеру, если постановщик утвердил задачу, то в 80% контор программисту придется делать круглый квадрат.
Если постановщик (сеньор-девелопер) утвердил круглый квадрат, то кодеру (джун-девелоперу), естестенно, нужно это выполнять.
А если джун девелопер не знает про круглые квадраты, но этому джуну кажется, что сеньор-постановщик дурак, то скорее всего у джуна просто Эффект Даннинга — Крюгера
Эффект Да́ннинга — Крю́гера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом не способны осознавать свои ошибки в силу низкого уровня своей квалификации[1]. Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать оценку своих способностей и страдать недостаточной уверенностью в своих силах, считая других более компетентными. Таким образом, менее компетентные люди в целом имеют более высокое мнение о собственных способностях, чем это свойственно людям компетентным, которые к тому же склонны предполагать, что окружающие оценивают их способности так же низко, как и они сами.
Для руководителей на любом уровне действует Принцип Питера: «в иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».
Из принципа следует, что руководящую должность возможно занимает человек из последних сил пытающийся на ней удержаться. Таких примеров много, люди успешно борются за пригретые кресла.
Из принципа следует, что руководящую должность возможно занимает человек из последних сил пытающийся на ней удержаться. Таких примеров много, люди успешно борются за пригретые кресла.
А из этого принципа разве не следует, что программисты ровно такие же?
Исходя из чего вы считаете, что вы лучше представляете ситуацию за пределами той маленькой функции или класса, которую прямо сейчас пишите?
А из этого принципа разве не следует, что программисты ровно такие же?
Принцип универсален.)
В сообщении, на которое я ответил, говорилось:
Если руководитель некомпетентен, то он не должен занимать свою должность.
В итоге, в системе реально работают те, кто не поднялся до своего уровня некомпетентности. Программист, кстати, постоянно балансирует на грани, но каждый раз эту грань отодвигает. ;-)
В системе постоянно пребывает достаточно сотрудников, которые ещё не достигли своего уровня некомпетентности; они-то и выполняют всю реальную работу. Кроме того, если система невелика, в ней может просто не оказаться достаточного количества должностей, чтобы все компетентные работники могли быть повышены до своего уровня некомпетентности.
Программист, кстати, постоянно балансирует на грани, но каждый раз эту грань отодвигает. ;-)
Это хорошие программисты постоянно учатся, развиваются, повышают квалификацию.
Это джуны повышают квалификацию просто и быстро.
А для большинства программистов уровень миддла — предел.
Не нужно обижаться — так есть и всегда было и будет во всех профессиях.
Программисты — никакая не особенная и не элитарная профессия в этом смысле.
Если у вас нет доступа, попросите.Это уже не «просто». Если брать совсем точно и докапываться до смысла слов, то если «просить», то имеют право и не дать. Если же «требовать», то это уже не «просто», т.к. надо обосновывать и ждать. Слово «просто» скрывает нежелание лица, употребившего его, брать на себя ответственность.
Увы, но проблема ведь в том, что разработчики не хотят/не умеют разговаривать с руководителями.
Мне представляется, что здесь вы слишком много хотите от разработчика или процитированная мысль инвертирована и проблема всё же здесь в компетентности руководителя, а не разработчика. Отмечу два, как мне видится, несоответствия.
Первое.
Эта мысль не очень хорошо вписывается в общий контекст параграфа о некомпетентности.
Разработчик может иметь знания и опыт в своей области вполне достаточные для эффективной деятельности, при этом не обладать обширными коммуникативными навыками. Да, безусловно:
Умение общаться с людьми такой же навык, как и все остальные.Ок, но этот навык никогда не был ключевым для позиции разработчика. Вряд ли кто-то будет спорить с тем, что требования к коммуникативным способностям на позиции «менеджер» (руководитель) всегда существенно выше, чем на позиции «разработчик».
Отсюда вытекает второе.
Налаживание, построение, обеспечение коммуникаций — задача руководителя.
Именно моя задача, как руководителя, обеспечить сотруднику эмоциональный комфорт в общении со мной, чтобы он не боялся со мной коммуницировать, не боялся лишний раз мне сообщить информацию, которую он считает важной или даже возразить. Именно моя задача донести до сотрудника, что мне действительно важно его мнение, т.к. я уважаю его как профессионала в своей области. Не надо бояться признавать, что мой сотрудник может лучше меня разбираться в каких-то вещах или деталях, особенно, если это так и есть. Полагаю, сказанное позволит исключить вариант «не хотят», ну, а вариант «не умеют» проще — в рамках той же моей задачи по обеспечению коммуникаций, если разработчик не может сходу и четко сформулировать мысль, то мне следует ему помочь.
Сам очень не люблю работать с начальствующими индивидами, которые предпочитают формат «я начальник — ты дурак», хотя менеджер должен уметь адаптироваться и приходилось всякое, считаю это крайне неэффективным и со своими сотрудниками я такого не допускаю.
Таким образом, мысль предыдущего комментатора:
Желание и умение со стороны разработчика, должно дополняться таким же желанием со стороны руководителя/пользователя.в целом верная, исходя из моего опыта, как руководителя, видится мне в более жёсткой форме:
«Желание и умение [коммуницировать] со стороны разработчика, должно обеспечиваться его руководителем».
Вы все правильно говорите, вовлечение разработчика в диалог полностью лежит на его руководителе. Но и разработчик тоже должен проявлять инициативу, когда у него возникают проблемы вне его компетенции. Например, если нужно арендовать сервер, а человек не распоряжается мат. средствами, то необходимо обратиться к руководителю.
Вы все правильно говорите, вовлечение разработчика в диалог полностью лежит на его руководителе.
Нет.
Разработчик уже ВИДИТ техническую проблему, о которой еще не знает руководитель.
Кто должен выйти на диалог?
Ну вот в логах ОС жесткий диск сервера ругается — скоро выйдет из строя.
Будем сидеть и ждать, пока он сдохнет и сервер выйдет из строя и тогда уже руководитель, узнает-увидет? Или купите за свой счет диски, не используя деньги компании, которые мимо руководителя использовать нельзя?
Тут речь, наверное, скорее не о том, кто должен первым начать конкретный сеанс общения, а о том, кто должен создать условия, при которых разработчик будет при необходимости выходить с инициативами к руководителю, не опасаясь за свою зарплату, должность и общее отношение к себе со стороны руководства.
выходить с инициативами к руководителю, не опасаясь за свою зарплату
Имхо, это вообще проблема не условий, а людей неуверенных в себе, которые почему то думают что спорить с начальством нельзя, что тебе начальство сделает после этого плохо.
Люди, начальство вас именно потому и наняло, что именно вы и являетесь специалистами, вы и делаете работу в конце концов. И именно вы и должны высказывать начальству замечания по тому как что работает с технической точки зрения.
Другое дело (а эти условия очень любят кадровики описывать при приеме на работу) — если ваша идея не прошла и начальство сказало «нет», то ничего страшного — это рабочий момент, просто продолжаете работать в том направлении, которое указало начальство.
В таком случае разработчик должен проявить инициативу и предупредить о рисках.
Были на практике случаи, когда откладывать было некуда, шел и покупал за свои. Все потраченные средства всегда возвращались в виде премии и других формах.
Были на практике случаи, когда откладывать было некуда, шел и покупал за свои. Все потраченные средства всегда возвращались в виде премии и других формах.
Идеи здравые, но на целую статью не тянут — только собрался почитать, а уже все закончилось, ну не Твиттер же все-таки…
Поручили мне сделать дешевый «велосипед» за восемь месяцев, что бы «импортозаместить» дорогое и более универсальное решение от N, — «мы на совещании прикинули, там все просто».
Позже выяснилось, что работать я буду фактически один, и на 80%! Очевидно, чтобы так изощренно надругаться над профессионализмом отдела разработки в N. «Мы же сделаем только нужное нам, поэтому будет быстро и просто».
Когда через год конца не было видно, начальник сказал, что в начале он мне про простоту плел, чтобы я не боялся. (Чепуха, они сам в это верили.) Угу. А я на 10000 рванул, как на 500… но не спекся. 3,5 года… Не забывайте умножать эстимацию на PI.
Позже выяснилось, что работать я буду фактически один, и на 80%! Очевидно, чтобы так изощренно надругаться над профессионализмом отдела разработки в N. «Мы же сделаем только нужное нам, поэтому будет быстро и просто».
Когда через год конца не было видно, начальник сказал, что в начале он мне про простоту плел, чтобы я не боялся. (Чепуха, они сам в это верили.) Угу. А я на 10000 рванул, как на 500… но не спекся. 3,5 года… Не забывайте умножать эстимацию на PI.
Да не вопрос, сделаю. Просто утройте мне зарплату.
В контексте русского языка приведенные фразы не столько означают уверенность в простоте требуемого, сколько обозначают ограничение ненужной инициативы исполнителя.
"Просто размести это где-нибудь на сервере" значит не более чем "размести это где-нибудь на сервере, и больше ничего делать с этим не надо", чтобы пациент не начал ненужной бурной деятельности по разворачиванию нового сервера, по написанию того, что нужно оазместить, с нуля, по замене "этого" чем-то "более прогрессивным" и т.п.
Ну да. Можно не раздумывая папку с логами разместить на системном разделе и даже не прикинуть, как быстро начнутся «просто» непредвиденности.
Скорее — сделай, только меня не спрашивай как, не зря же ты зарплату получаешь.
Только нет гарантий, что после того, как ты «просто разместишь» где-то на сервере, не выяснится, что надо было как раз новый сервер развернуть (это само собой подразумевалось же, как не догадался?).
У каждого свой опыт, конечно, но я вот чаще сталкивалась с вариантом, когда за фразой «просто сделай X» скрывалось нежелание/неумение/отсутствие времени разобраться в вопросе. И если начинаешь уточнять, озвучивать граничные случаи, возможные проблемы и т. д., то в ответ получаешь что-то в духе: «Ты все УСЛОЖНЯЕШЬ». Видимо для кого-то мои потуги выглядят как «ненужная бурная деятельность».
У каждого свой опыт, конечно, но я вот чаще сталкивалась с вариантом, когда за фразой «просто сделай X» скрывалось нежелание/неумение/отсутствие времени разобраться в вопросе. И если начинаешь уточнять, озвучивать граничные случаи, возможные проблемы и т. д., то в ответ получаешь что-то в духе: «Ты все УСЛОЖНЯЕШЬ». Видимо для кого-то мои потуги выглядят как «ненужная бурная деятельность».
Постановка задачи "просто сделай это" не подразумевает ничего сверх приказанного.
Если оно почему-то подразумевается хвостом за задачей (да еще, естественно, и ответственность, если что-то пойдет не так), то не слово "просто" тому виной. Более того, оно будет абсолютно точно так же и без слова "просто" в формулировке.
Слово «просто» ни в чем не виновато, как и любое другое слово. Просто (вот оно, зараза) в статье оно приводится как некий «тревожный звоночек», на который следует обратить внимание. Да, одинаково плохо может быть как с ним, так и без него.
Мне мила эта мысль, честно. И хочется, чтобы так всегда и было. Но мне в последнее время редко везет на четкие постановки задач.
Есть еще другой, тоже неприятный вариант, когда вроде бы и понятно, что от тебя хотят, можно «взять и сделать», но это не вписывается в существующую логику работы системы, затруднит поддержку и с большой вероятностью приведет к проблемам. И сомневаюсь, что разгребать их будет тот, кто задачу ставил.
Постановка задачи «просто сделай это» не подразумевает ничего сверх приказанного.
Мне мила эта мысль, честно. И хочется, чтобы так всегда и было. Но мне в последнее время редко везет на четкие постановки задач.
Есть еще другой, тоже неприятный вариант, когда вроде бы и понятно, что от тебя хотят, можно «взять и сделать», но это не вписывается в существующую логику работы системы, затруднит поддержку и с большой вероятностью приведет к проблемам. И сомневаюсь, что разгребать их будет тот, кто задачу ставил.
«У меня есть идея! Сделайте мне сайт, как этот как его… Гугл!
Там всего две странички — страничка поиска и страничка с результатом поиска! Денег сейчас конечно нет, но прибылью поделюсь!!!!»
Там всего две странички — страничка поиска и страничка с результатом поиска! Денег сейчас конечно нет, но прибылью поделюсь!!!!»
Чтож, я тоже поделюсь, опасным словом — автоматически.
Старые комментарии автоматически удаляются.
Картинки автоматически ресайзятся.
Старые комментарии автоматически удаляются.
Картинки автоматически ресайзятся.
Взгляните на инструкцию к нашим мотоциклами, там все просто "просто возьмите болванку и по чертежу, сделайте деталь", a тут какаета кнопка, меню. Ну а так слово как по мне паразит.
Вспомнилась книга «Микроконтроллеры? Это же просто!». В четырёх томах.
Когда я слышу слово «просто», я хватаюсь за монтировку. Ее есть у меня. Обычно это означает, что человек, который произносит данное слово, понятия не имеет о чем говорит.
Помимо "просто" меня жутко бесит слово "ВСЕ". Употребляется в контексте, когда нужно добавить новый функционал, но заказчик/менеджер не имеет представления о всей конкретике работы системы, либо тупо не хочет заморачиваться.
— В какую форму добавить коментарий? — Во ВСЕ!
— В каком сценарии вызывать этот интерфейс? — Во ВСЕХ!
— Для пользователей каких ролей сделать проверку? — Для ВСЕХ!
— Какие интерфейсы экспортировать для удаленного использования? — ВСЕ!
— Не, ну тут-то не надо было добавлять. А вы что, везде добавили что ль?
С другой стороны, мне нравится когда заказчик говорит — возьмите всё, а там разберётесь что нужно, а что нет.
С другой стороны, мне нравится когда заказчик говорит — возьмите всё, а там разберётесь что нужно, а что нет.
Лично у меня давно выработался рефлекс на абсолютные утверждения в требованиях заказчика: слова «все», «всегда», «никогда», «везде», «нигде» и т.п.
В подавляющем большинстве случаев наличие абсолютных утверждений говорит о том, что требования не продуманы и заказчик не представляет до конца, о чем говорит.
Еще интересный случай, когда заказчик говорит «95% процентов пользователей этой функцией все равно пользоваться не будет, и поэтому нет смысла ее подробно описывать».
В подавляющем большинстве случаев наличие абсолютных утверждений говорит о том, что требования не продуманы и заказчик не представляет до конца, о чем говорит.
Еще интересный случай, когда заказчик говорит «95% процентов пользователей этой функцией все равно пользоваться не будет, и поэтому нет смысла ее подробно описывать».
Вспоминается случай из собственной практики из далёкого 2011 года:
— Спасибо, вы сделали нам хороший сайт-визитку, нам всё нравится! А вы не могли бы просто добавить в него ещё три странички?
— Просто три странички? Это возможно. Какие именно странички?
— Социальную сеть, сервис знакомств и раздел поиска работы, с резюме и вакансиями. Что-нибудь простое, по типу JobRu.
— Спасибо, вы сделали нам хороший сайт-визитку, нам всё нравится! А вы не могли бы просто добавить в него ещё три странички?
— Просто три странички? Это возможно. Какие именно странички?
— Социальную сеть, сервис знакомств и раздел поиска работы, с резюме и вакансиями. Что-нибудь простое, по типу JobRu.
Так вы добавили?
Увы, пришлось заказчику вежливо отказать, сославшись на договор и чётко прописанное ТЗ, в котором заранее прописали весь список разделов и страниц их небольшого сайта.
А спустя пару лет они снова обратились на помощью, и пароль на их аккаунте хостинга в то время был dolg30000, но это уже совсем другая история ...
А спустя пару лет они снова обратились на помощью, и пароль на их аккаунте хостинга в то время был dolg30000, но это уже совсем другая история ...
НЛО прилетело и опубликовало эту надпись здесь
Туда же слова маркеры безответственности: это надо сделать "срочно", на это "нет времени".
Это ваше «просто» имеет еще и внебрачного ребенка по имени «потом»
«Потом» задокументируем
«Потом» потестим
«Потом» обсудим это с заказчиком
«Потом» посчитаем, укладывается ли это в бюджет
Сначала они «просто» что-то там добавили, и больше ты никогда не сможешь понять, кто, что и зачем и как с этим теперь жить
«Потом» задокументируем
«Потом» потестим
«Потом» обсудим это с заказчиком
«Потом» посчитаем, укладывается ли это в бюджет
Сначала они «просто» что-то там добавили, и больше ты никогда не сможешь понять, кто, что и зачем и как с этим теперь жить
«Просто возьми на себя риски того, что всё окажется намного менее просто, чем кажется мне сейчас. Просто рискни своей репутацией и рабочим местом».
Отличный пост. Здесь в комментариях наверняка будут люди, которые помогут мне разобраться. Как так получается, что для изменения текста рядом с формой, нужно ждать следующего релиза, а когда наконец выходит этот релиз через 3 месяца, то у пользователей в браузерах вся верстка едет?
НЛО прилетело и опубликовало эту надпись здесь
Итак, подумаем, придумаем… :)
1) Текст изменится только в следующем релизе, т.к. выдавать новый только ради текста не имеет смысла, больше возни с выдачей (деплоем). Итого — запилили новый текст в ветке которая для него и создана, а она еще в разработке/тестировании, и в нее возможно еще пару изменений внесут по ходу дела, что откладывает релиз.
2) Плохо тестировали, или не тестировали. Или по ходу доделывания ветки с новым релизом внесли изменения в одном месте, а аукнулось в нескольких других (глобальные стили), опять же не проверили где используются и не прошли смоук тест.
И статья говорит об этом, «просто» добавили текст.
1) Текст изменится только в следующем релизе, т.к. выдавать новый только ради текста не имеет смысла, больше возни с выдачей (деплоем). Итого — запилили новый текст в ветке которая для него и создана, а она еще в разработке/тестировании, и в нее возможно еще пару изменений внесут по ходу дела, что откладывает релиз.
2) Плохо тестировали, или не тестировали. Или по ходу доделывания ветки с новым релизом внесли изменения в одном месте, а аукнулось в нескольких других (глобальные стили), опять же не проверили где используются и не прошли смоук тест.
И статья говорит об этом, «просто» добавили текст.
— А ты правда ПМ?
— Да
— Скажи что-нибудь «На ПМоском»
— Серега, просто размести эту кнопку немного левее формы и скинь мне скрин, как это выглядит. Я покажу заказчику и если что немного подвигаем влево-вправо!
— Офигеть
— Да
— Скажи что-нибудь «На ПМоском»
— Серега, просто размести эту кнопку немного левее формы и скинь мне скрин, как это выглядит. Я покажу заказчику и если что немного подвигаем влево-вправо!
— Офигеть
На одной работе был начальник, который пытался на MS Access сделать себе инструмент, чтобы он у себя в кабинете кнопки двигал, а разрабатываемые дельфийские проекты (десктопные мультимедии) подхватывали бы изменения.
И как…
Могли быть варианты? Сначала он огорошил разработчика, потребовав скопировать ему файл серверной базы данных. И никак не мог понять, почему тот не может ему его дать.
Больше не помню, чтобы были результаты. Маразм крепчал и я ушел через полгода. Он был креативен, как ребенок. Но разработчикам, мотивации за ним угнаться хронически не хватало. Фирма жила, до позапрошлого года. С ним или без него не знаю.
Больше не помню, чтобы были результаты. Маразм крепчал и я ушел через полгода. Он был креативен, как ребенок. Но разработчикам, мотивации за ним угнаться хронически не хватало. Фирма жила, до позапрошлого года. С ним или без него не знаю.
Напрягаюсь от задач, где слово «просто» фигурирует. Однако профи, опыт и любознательность на три голоса убеждают пообщаться-уточнить. За этим страшным словом иногда просто:
1. Желание получить минимально работающий прототип (Для дальнейшей доработки или решения срочных бизнес-проблем)
2. Желание сэкономить (Не скажешь «просто» — примут за наивняка, завысят смету, подлецы)
3. Неверная оценка трудоемкости (Клиент, в общем-то, не обязан разбираться мелочах и влёт котировать по рынку произвольную задачку. Если правильно объяснить, разумный — поймёт)
4. Там действительно всё просто, оценка верная, заказчик разбирающийся и прижимистый, переплачивать не хочет (Имеет право)
Но есть у этого словечка, разумеется, и поганая сторона:
1. «Я уверен что тут всё просто, чего вы меня разводите? Мой бюджет $15»
2. «Я программист с 150-летним стажем, сам делать не могу/не хочу/слишком занят, но из тебя, батрак, соки повыжму и жилы повытащу — на пустые неоплаченные разговоры времени в избытке»
3. «Я считаю себя весьма хитрым малым, я разбил свой проект на 100 кусочков, теперь каждый из них „просто“ кусочек, за который стыдно много взять, на чём я и сыграю, твой номер — 67й»
1. Желание получить минимально работающий прототип (Для дальнейшей доработки или решения срочных бизнес-проблем)
2. Желание сэкономить (Не скажешь «просто» — примут за наивняка, завысят смету, подлецы)
3. Неверная оценка трудоемкости (Клиент, в общем-то, не обязан разбираться мелочах и влёт котировать по рынку произвольную задачку. Если правильно объяснить, разумный — поймёт)
4. Там действительно всё просто, оценка верная, заказчик разбирающийся и прижимистый, переплачивать не хочет (Имеет право)
Но есть у этого словечка, разумеется, и поганая сторона:
1. «Я уверен что тут всё просто, чего вы меня разводите? Мой бюджет $15»
2. «Я программист с 150-летним стажем, сам делать не могу/не хочу/слишком занят, но из тебя, батрак, соки повыжму и жилы повытащу — на пустые неоплаченные разговоры времени в избытке»
3. «Я считаю себя весьма хитрым малым, я разбил свой проект на 100 кусочков, теперь каждый из них „просто“ кусочек, за который стыдно много взять, на чём я и сыграю, твой номер — 67й»
На самом деле, для заказчика «просто», «да там ерунда» — вполне очевидная и обоснованная (на его уровне) оценка задачи. Это нужно понимать и принимать как данность. Заказчик не обязательно хочет умышленно занизить сроки проекта, но у него в голове держится только конечный результат (новая кнопка или страница) и он не понимает, что для этого потребуется, возможно, пересматривать архитектуру решения или написать кучу кода. Да и не обязан он это понимать.
Задача исполнителя — согласиться со сроками, либо опровергнуть эту оценку и аргументированно дать свою, либо отказаться от работы вообще (если, конечно, ты не наемный сотрудник у которого не всегда есть такая возможность).
Свежий пример: буквально месяц назад, объявился мой давний работодатель и попросил меня «по старой дружбе» внести изменения в разработанную 10+ лет назад систему. Цитирую — «Там все просто, работы на 2-3 часа максимум».
Сходу понимая, что это нереальные сроки (ведь я уже и забыл тот проект напрочь, мне только вспоминать, как минимум, день потребуется) и уточнив задачи — я осторожно дал оценку на выполнение задачи на порядок выше — в районе 30-40 часов и объяснил почему. Работодатель подумал, и согласился на эти сроки. В итоге, по факту вышло 25 часов, что вполне устроило всех и не было ни для кого неожиданностью.
Так что не нужно боятся этих «просто», а нужно уметь с ними работать.
Задача исполнителя — согласиться со сроками, либо опровергнуть эту оценку и аргументированно дать свою, либо отказаться от работы вообще (если, конечно, ты не наемный сотрудник у которого не всегда есть такая возможность).
Свежий пример: буквально месяц назад, объявился мой давний работодатель и попросил меня «по старой дружбе» внести изменения в разработанную 10+ лет назад систему. Цитирую — «Там все просто, работы на 2-3 часа максимум».
Сходу понимая, что это нереальные сроки (ведь я уже и забыл тот проект напрочь, мне только вспоминать, как минимум, день потребуется) и уточнив задачи — я осторожно дал оценку на выполнение задачи на порядок выше — в районе 30-40 часов и объяснил почему. Работодатель подумал, и согласился на эти сроки. В итоге, по факту вышло 25 часов, что вполне устроило всех и не было ни для кого неожиданностью.
Так что не нужно боятся этих «просто», а нужно уметь с ними работать.
Я всегда напрягаюсь, когда слышу от неайтишных заказчиков "в реальном времени". Под этим на моей памяти имелось в виду что угодно, включая обновления раз в месяц(!) по распарсенным документам, которые отправляет финансовый отдел, но только не знакомый нам термин.
> просто размести это где-то на сервере
Если «просто» проанализировать фразу, то тому кто произнес её, будет очень «просто» ответить на все эти вопросы:
1) «просто размести»: ОК, это я умею, сейчас сделаю, но…
2) «это»: что конкретно? в каком формате? какого объема? а где это всё взять? а у кого ключи?
3) «где-то»: а где? по какому адресу? а в какой стране? а на карте где точка? а кто знает?
4) «на сервере»: сервер какого типа? URL? не понятно, что это такое? а кто хостер? и это не понятно? а хостинг оплачен? доменное имя какое-то есть? а оно оплачено? а кто будет платить и когда? а у кого пароли? а объем хостинга размером подходит для п.2? а почему «просто» выглядит не очень просто?
Если «просто» проанализировать фразу, то тому кто произнес её, будет очень «просто» ответить на все эти вопросы:
1) «просто размести»: ОК, это я умею, сейчас сделаю, но…
2) «это»: что конкретно? в каком формате? какого объема? а где это всё взять? а у кого ключи?
3) «где-то»: а где? по какому адресу? а в какой стране? а на карте где точка? а кто знает?
4) «на сервере»: сервер какого типа? URL? не понятно, что это такое? а кто хостер? и это не понятно? а хостинг оплачен? доменное имя какое-то есть? а оно оплачено? а кто будет платить и когда? а у кого пароли? а объем хостинга размером подходит для п.2? а почему «просто» выглядит не очень просто?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ГЫ. да это ж про меня…
Буквально недавно скинул разработчикам задачу «просто скопируйте ее с другой и подмените настройки» пилят уже второй трехнедельный спринт, и это «просто» в начальной формулировке уже вызывает приступы истерического хохота у некоторых членов команды (включая меня самого :) ).
Буквально недавно скинул разработчикам задачу «просто скопируйте ее с другой и подмените настройки» пилят уже второй трехнедельный спринт, и это «просто» в начальной формулировке уже вызывает приступы истерического хохота у некоторых членов команды (включая меня самого :) ).
Пишу программы для промышленных установок. Технологи любят выражение как-нибудь. В какой-то момент при составлении алгоритма натыкаешься на неопределенность и спрашиваешь у технологов. Те пожимают плечами — мы не знаем точно, как должно быть, сделай пока как нибудь, потом подправим. Морщишь мозг — придумываешь варианты, все их описываешь, вносишь в программу. Наступает ПНР — технологи ходят с недовольными лицами и жалуются начальству, что установка работает как-то не так! OMG дай мне сил.
Заказчики оно такие… ""Я считаю у нас всё готово, что вы там опять нам делаете..."
Для меня самые раздражающие слова в постановке задач «Короче» и «Все» (в применении «проверь все» и т.п.).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самое опасное слово в разработке программного обеспечения