Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
Мне понравилось. Тоже сделал для себя кое какие выводы…
Поделитесь соображениями, если не сложно :)
ну как минимум фраза надо хочется даже самому умному идеальному заказчику. — И мне кажется все таки что первое лучше) А все остальное — проблемы заказчика. Если он обратился «туда где не умеют как он хочет» — виноват сам. Критично отчасти, но…
… разработчик полностью лишался пространства для манёвра...заставляется задуматься о том, что лучше: чтобы разработчик делал как он умеет и в срок, или как
Интересно, спасибо.
Очень интересно для меня, как для человека, который сам никогда не был заказчиком. Но появилась пара вопросов. Почему проект был отдан на аутсорс, если деньги такие же, как Вы бы сами делали для других? Неужели это выгоднее, чем дождаться завершения текущих работ и сделать самим? Не говорит ли вся эта ситуация о низком профессионализме исполнителя?
Банальная ситуация — все свои разработчики заняты в долгосрочных проектах. Отдать на аутсорс казалось дешевле, потому что не было затрат на поиск дополнительного персонала, его обучение и пр…
> Неужели это выгоднее, чем дождаться завершения текущих работ и сделать самим?
Потому, что всех денег не заработать и своим разработчикам тоже нужно платить зарплату. Не нарушая режима работы, делаем то, что хотим. Это как кредит под процент ниже инфляции. Вполне допускаю в своем воображении такую ситуацию. Там проект может быть на год, а софтину хочется сейчас же! Там много чего может быть, что может повлиять на принятие такого решения.
> Не говорит ли вся эта ситуация о низком профессионализме исполнителя?
Нет, это говорит только о том, что исполнитель, за всю свою жизнь, физически не сможет воспользоваться всеми возможными изобретенными велосипедами.
Речь же не о том, что разработчик не умеет пользоваться хвостовой рекурсией, а о менее абстрактных вещах. Скорее это звучит так: «Конечно я понимаю как это сделать, просто никогда раньше не делал».
Да и знаете ли, все же несмотря на всю «техничность» специальности, например, программиста, я считаю эту профессию крайне творческой, и всегда хочется внедрить свое удачное решение, когда чужое неуклюжее, всегда кажется не самым удачным.
Это как если к вам подойдет незнакомый дядя и скажет: «я хочу чтобы ты женился на Профессоре Ивановой, потому… потому, что я так хочу». А до этого требования казалось, что ты сам можешь выбрать свой путь, хотя мозгом понятно, что Профессор Иванова с блестящим умом и совершенной фигурой — просто мечта идиота, но осадочек остался.
Потому, что всех денег не заработать и своим разработчикам тоже нужно платить зарплату. Не нарушая режима работы, делаем то, что хотим. Это как кредит под процент ниже инфляции. Вполне допускаю в своем воображении такую ситуацию. Там проект может быть на год, а софтину хочется сейчас же! Там много чего может быть, что может повлиять на принятие такого решения.
> Не говорит ли вся эта ситуация о низком профессионализме исполнителя?
Нет, это говорит только о том, что исполнитель, за всю свою жизнь, физически не сможет воспользоваться всеми возможными изобретенными велосипедами.
Речь же не о том, что разработчик не умеет пользоваться хвостовой рекурсией, а о менее абстрактных вещах. Скорее это звучит так: «Конечно я понимаю как это сделать, просто никогда раньше не делал».
Да и знаете ли, все же несмотря на всю «техничность» специальности, например, программиста, я считаю эту профессию крайне творческой, и всегда хочется внедрить свое удачное решение, когда чужое неуклюжее, всегда кажется не самым удачным.
Это как если к вам подойдет незнакомый дядя и скажет: «я хочу чтобы ты женился на Профессоре Ивановой, потому… потому, что я так хочу». А до этого требования казалось, что ты сам можешь выбрать свой путь, хотя мозгом понятно, что Профессор Иванова с блестящим умом и совершенной фигурой — просто мечта идиота, но осадочек остался.
. И если он не мог что-то реализовать (особенно на фронт-енде), то у него просто не было возможности сделать по-другому – сделать так, как умеет. В результате любую проблему приходилось решать самым сложным способом, потому что обходной путь всегда был отрезан.
Хмм. А подойти и сказать — «вот так реализовать проблематично, придётся сплясать с бубном, но можно сделать так, разница для пользователя не велика, а разница во времени разработки — в 3 раза?» Мало ли, вдруг и договоритесь. Попробовать то можно же.
Тут может ещё и от разработчика зависит? Я вот дико люблю такие детализированные проекты, когда остаётся только продумывать «невидимую» заказчику часть, но когда встречается момент «это невозможно/возможно, но сложно/сильно трудозатратно/несёт подводные камни» — иду и спрашиваю, «а может быть...». И судя по идеальности такого заказчика как вы, наверняка договорились бы. :)
Хмм. А подойти и сказать — «вот так реализовать проблематично, придётся сплясать с бубном, но можно сделать так, разница для пользователя не велика, а разница во времени разработки — в 3 раза?» Мало ли, вдруг и договоритесь. Попробовать то можно ж
Мы пытались так делать. К слову у меня ушла пара месяцев просто на то, чтобы приучить разработчиков хотя бы оценивать сложность реализации экронов перед их вёрсткой и высказывать своё мнение. Но даже после этого всё равно случались заковырки, когда какой-нибудь pop-up упорно не хотел нормально появляться-скрываться.
Конечно, после двух недель мучений разработчик предлагал, к примеру всю форму перенести в лайтбокс, но в середине проекта менять концепцию интерфейса нельзя — поэтому приходилось биться головой об стену и учиться-учиться-учиться. А это куча дополнительного времени и денег.
Как уже сказали выше, это говорит о «низком профессионализме исполнителя».
Еще бы админов отправляли на практику бухгалтером, тоже польза была бы.
лучше бухгалтеров на курсы компьютерной грамотности.
в 2009 году в холдинг пришла бухгалтер, которая смотрела на компьютер с ужасом, т.к. до этого с ним вообще не пересекалась. в 2009 году!
в 2009 году в холдинг пришла бухгалтер, которая смотрела на компьютер с ужасом, т.к. до этого с ним вообще не пересекалась. в 2009 году!
Скажу как админ с первым образованием бух.учета и аудита.
Лучше сделать экзамен по компьютерной грамотности в школах, чтобы не было людей, которые считают монитор компьютером.
Лирическое отступление:
Первое бухгалтерское образование и опыт работы по специальности позволяет мне действительно учить бухгалтеров, которые пытаются «учить» меня делать мою работу.
Со мной не рискуют спорить, и это приятно.
Также замечу что хороших бухгалтеров очень сложно найти.
Они есть, но также сложно находимы как хорошие сисадмины.
И в обоих случаях это вопрос самоорганизации, ответственности и порядочности, а этому не научишься.
Лучше сделать экзамен по компьютерной грамотности в школах, чтобы не было людей, которые считают монитор компьютером.
Лирическое отступление:
Первое бухгалтерское образование и опыт работы по специальности позволяет мне действительно учить бухгалтеров, которые пытаются «учить» меня делать мою работу.
Со мной не рискуют спорить, и это приятно.
Также замечу что хороших бухгалтеров очень сложно найти.
Они есть, но также сложно находимы как хорошие сисадмины.
И в обоих случаях это вопрос самоорганизации, ответственности и порядочности, а этому не научишься.
Я тоже пришел к выводу о том, что необходимо давать разработчику пространство для маневра. В противном случае сложность разработки для разработчика возрастет и кпд разработки будет ниже.
Причем точно такое же, но только с перламутровыми пуговицами — и в пять раз меньше времени на реализацию…
Но ТЗ уже подписано, все согласовано… И если таких вещей куча — это создает огромную проблему.
Например, заказчик подробно описал админку. А исполнитель использует свои наработки для этого или вообще CMS. Но в ТЗ четкие указания как и что должно выглядеть. Хотя по большому счету заказчику все равно и вид админки вообще не принципиален был…
Но ТЗ уже подписано, все согласовано… И если таких вещей куча — это создает огромную проблему.
Например, заказчик подробно описал админку. А исполнитель использует свои наработки для этого или вообще CMS. Но в ТЗ четкие указания как и что должно выглядеть. Хотя по большому счету заказчику все равно и вид админки вообще не принципиален был…
Я тоже пришел к выводу о том, что необходимо давать разработчику пространство для маневра. В противном случае сложность разработки для разработчика возрастет и кпд разработки будет ниже.
Ну это палка о двух концах. Сколько было случаев, когда после таких манёвров случались диалоги типа:
— А я думал, пуговицы будут перламутровыми
— В ТЗ цвет не прописан, мы сделали на своё усмотрение
— Но это же очевидно, что они должны быть перламутровые!!!
— Перламутровые вообще не будут застёгиваться!
— Нет, делайте перламутровые, я ваш заказчик
…
— Ой, а чё не застёгиваются?
Я имел ввиду, что необходимо обсуждать все шаги с исполнителем. У него должна быть свобода действия, но он должен информировать заранее об этих действиях. Поставить ему четкую задачу, но сказать что некоторые ее части он может выполнить по-своему, если считает что это будет эффективнее. Если исполнитель решает внести какие-то изменения, то он просто информирует об этом заказчика. Если заказчик несогласен, то он возражает, если же его устраивает и такой вариант, то он одобряет. Это мое видение этого вопроса, из моего личного опыта. Возможно у других оно будет другим.
Тогда это не то. Вы говорите о праве исполнителя иметь своё мнение и пытаться убедить в нем заказчика. На мой взгляд — это само собой разумеется в любом проекте с адекватным заказчиком.
Под пространством для манёвра я полагаю возможность разработчика какие-то вещи делать по своему при том, что заказчик не будет иметь права требовать переделки даже если ему не понравится. В моём случае таким пространством были технологии разработки и правила написания кода. Но этого видимо мало.
Под пространством для манёвра я полагаю возможность разработчика какие-то вещи делать по своему при том, что заказчик не будет иметь права требовать переделки даже если ему не понравится. В моём случае таким пространством были технологии разработки и правила написания кода. Но этого видимо мало.
Я несколько лет назад понял, что для студии порой нет ничего хуже, чем заказ внутри себя, для внутренних целей.
Почему-то для заказчика пишется ТЗ, все прорабатывается и т. п.
А для себя считается, зачастую, что можно и так. Все типа профессионалы, все всё понимают и знают и типа вообще особо тратить время на ТЗ не нужно, можно сразу кодить. Так же верстать и рисовать все страницы тоже не надо…
И начинаются фейлы, типа комментарии могут оставлять только зарегистрированные, но ни формы регистрации, не личного кабинета, ни даже кнопки «выход» никто не запланировал…
Почему-то для заказчика пишется ТЗ, все прорабатывается и т. п.
А для себя считается, зачастую, что можно и так. Все типа профессионалы, все всё понимают и знают и типа вообще особо тратить время на ТЗ не нужно, можно сразу кодить. Так же верстать и рисовать все страницы тоже не надо…
И начинаются фейлы, типа комментарии могут оставлять только зарегистрированные, но ни формы регистрации, не личного кабинета, ни даже кнопки «выход» никто не запланировал…
Или так. Зачем тратить время на эти дурацкие схемы? Если непонятно — пусть разработчик подойдет к дизайнеру и спросит, как что работает :)
А при чем тут дизайнер? Дизайнер будет решать как будут работать коментарии? Нет. Зачастую они рисуют красивую картинку, вовсе не задумываясь глубоко над возможными вариантами.
По идее менеджер это все продумывать должен. Но менеджер должен все эти вопросы решить был еще до передачи программисту.
Но представить ситуацию, с теми же комментариями — пришел программист, сказал что нет этих страниц. Менеджер включился, пришлось поставить задачи дизайнеру, верстальщику, нарастить функционал. Программист в это время ждет. Потом опять очередной не продуманный шаг и опять задержка.
Или программист не задумался над тем, что комментарии вообще то должны премодерироваться и забацал как есть. Потом его попросили исправить, чтобы они появлялись после подтверждения. Программист отвлекся от другого проекта, быстро сделал эту фичу, но не задумался, что админ никак не узнает о новых комментариях (его же не просили уведомление делать или список ожидающих модерацию комментариев).
И так далее и т. п.
Сталкивался с тем, что программист садился и сам писал для себя ТЗ, так как порой лучше сразу продумать функционал, зафиксировать его на бумаге (так как все в голове не удержишь) и уже только кодить, каждый раз не вдумываясь в то, оптимально ли сейчас решается и нет ли подводных камней.
По идее менеджер это все продумывать должен. Но менеджер должен все эти вопросы решить был еще до передачи программисту.
Но представить ситуацию, с теми же комментариями — пришел программист, сказал что нет этих страниц. Менеджер включился, пришлось поставить задачи дизайнеру, верстальщику, нарастить функционал. Программист в это время ждет. Потом опять очередной не продуманный шаг и опять задержка.
Или программист не задумался над тем, что комментарии вообще то должны премодерироваться и забацал как есть. Потом его попросили исправить, чтобы они появлялись после подтверждения. Программист отвлекся от другого проекта, быстро сделал эту фичу, но не задумался, что админ никак не узнает о новых комментариях (его же не просили уведомление делать или список ожидающих модерацию комментариев).
И так далее и т. п.
Сталкивался с тем, что программист садился и сам писал для себя ТЗ, так как порой лучше сразу продумать функционал, зафиксировать его на бумаге (так как все в голове не удержишь) и уже только кодить, каждый раз не вдумываясь в то, оптимально ли сейчас решается и нет ли подводных камней.
А при чем тут дизайнер? Дизайнер будет решать как будут работать коментарии? Нет. Зачастую они рисуют красивую картинку, вовсе не задумываясь глубоко над возможными вариантами.
В моём случае всё, что отображается на мониторе — сфера компетенции UX-дизайнера. Менеджер должен описать функцию премодерации, а уже дизайнер решает — куда будет приходить уведомление о новом комменте, где будут кнопки для его просмотра, какие будут варианты у админа по взаимодействию с автором, будут ли при этом показыаться его последние 10 сообщений и пр…
А я встречался с обратной ситуацией — когда все «внешние» проекты очень срочные, делали их с прицелом на дедлайн, а не на качество. Зато собственный проект временных рамок не имел и хотелось сделать всё качественно и красиво. Итог — за три года разработки написали два собственных фреймворка, большую документацию и лишь на четвёртый год несложный, в общем-то проект еле дотянул до релиза.
Заказчик ставит вопрос «ЧТО надо делать», исполнитель выбирает «КАК он это будет делать»
А может частично проблема в том, что у исполнителя нету пространства для творчества?
Если ему подробно расписать «как надо делать», вместо «что надо делать», то интерес работе может пропасть.
Если ему подробно расписать «как надо делать», вместо «что надо делать», то интерес работе может пропасть.
Браво!
Я будучи заказчиком всегда давал задачи на словах, и редко в одну страницу. Иногда даже в одно предложение. Далее давал максимум пространства для маневра. Отсекая тех, кто не может делать хорошо, на уровне своего внутреннего чутья. Зато получились супер классные отношения с теми, кто способен сам маневрировать и обосновать свои маневры в случае вопросов.
Но так сложилось что теперь я сам исполнитель. Создана своя веб студия и хорошо получается работать с теми, кто дает задачи абстрактно, по целям (а цели измеримы как мы понимаем), и тут маневров может быть куча. И парюсь с теми, кто и цель поставить не может, и нарисовать ничего не может, зато может поменять свое мнение на 5 раз за день. И не знаешь чего делать и как угодить.
Мечтал найти того кто сможет прорисовать макет страницы. Но не нашел. А после этой статьи понял что и искать не стоит :) Надо фокусироваться на первом типе заказчиков, когда задача ставится с тем уровнем детализации которого достаточно и не словом (картинкой) больше. В соответствии с философией лезвия Оккамы.
Очень полезный очерк. Спасибо!
Я будучи заказчиком всегда давал задачи на словах, и редко в одну страницу. Иногда даже в одно предложение. Далее давал максимум пространства для маневра. Отсекая тех, кто не может делать хорошо, на уровне своего внутреннего чутья. Зато получились супер классные отношения с теми, кто способен сам маневрировать и обосновать свои маневры в случае вопросов.
Но так сложилось что теперь я сам исполнитель. Создана своя веб студия и хорошо получается работать с теми, кто дает задачи абстрактно, по целям (а цели измеримы как мы понимаем), и тут маневров может быть куча. И парюсь с теми, кто и цель поставить не может, и нарисовать ничего не может, зато может поменять свое мнение на 5 раз за день. И не знаешь чего делать и как угодить.
Мечтал найти того кто сможет прорисовать макет страницы. Но не нашел. А после этой статьи понял что и искать не стоит :) Надо фокусироваться на первом типе заказчиков, когда задача ставится с тем уровнем детализации которого достаточно и не словом (картинкой) больше. В соответствии с философией лезвия Оккамы.
Очень полезный очерк. Спасибо!
Ну «ТЗ» в одно предложение думаю вообще не имеет права на существование. Вопросы в любом случае появляются сразу. Если человек придет к вам в студию и скажет «Мне нужен крутой сайт», вы поймете его и приступите к «свободной» работе? И это же не пустые слова, бывают и такие заказчики. И только в ходе длительных переговоров может выясниться что ему нужен свой трёхстраничник в сети, но так чтобы все о нем знали.
Имеет :) Другой вопрос по какой задаче? Если «крутой сайт», то ТЗ в одну строчку — это все равно что выстрел себе в лоб. Понятно что такие ТЗ нужно детализировать. Я ж написал что соблюдается принцип бритвы Оккамы. Если есть необходимость в детализации — значит она нужна и будет. Более того, иногда в ТЗ даже макеты рисовал, если было явное понимание что без макета нормально не объяснить.
Ну я это все к тому что свобода конечно нужна, но в разумных пределах. То есть важно найти золотую середину, и не увлечь заказчика подробностями, чтобы самого себя не загнать в жесткие рамки… а потом еще и слушать «ну вы же сами так говорили» И как бы ситуация с макетом может оказаться плачевной. Объясняй потом все отделом этому заказчику разницу между макетом и изделием =)
Тут есть один нюанс. Попробую объяснить.
Как подрядчику по разработке ПО у меня лучше всего получалось работать с теми заказчиками, кто формулировал требования на уровне бизнес-целей и общих задач типа:
Тогда работать лучше всего, поскольку на нас и проектирование и разработка, то пропасти между ними нет. Проектируем с учетом своих возможностей и способностей. Максимум пространства для маневра. И заказчик доволен — у него всё работает.
Но это возможно только когда заказчик является конечным пользователем.
В моём же случае я был вендором, отдавшим разработку на аутсорсинг. Для меня — это коммерческий проект. Результат работы я намереваюсь продавать. Соответственно, если мой подрядчик, к примеру, реализует все функции но интерфейс будет на уровне 90-х годов — мой сервис никто не купит. Поэтому мои ожидания более конкретны и ТЗ более детализировано.
В первом случае чем больше у разработчика пространства для манёвра — тем ниже риски у заказчика.
Во втором случае один неправильный манёвр разработчика может погубить весь бизнес.
Как подрядчику по разработке ПО у меня лучше всего получалось работать с теми заказчиками, кто формулировал требования на уровне бизнес-целей и общих задач типа:
Система должна обеспечивать возможность просмотра документа.Тогда работать лучше всего, поскольку на нас и проектирование и разработка, то пропасти между ними нет. Проектируем с учетом своих возможностей и способностей. Максимум пространства для маневра. И заказчик доволен — у него всё работает.
Но это возможно только когда заказчик является конечным пользователем.
В моём же случае я был вендором, отдавшим разработку на аутсорсинг. Для меня — это коммерческий проект. Результат работы я намереваюсь продавать. Соответственно, если мой подрядчик, к примеру, реализует все функции но интерфейс будет на уровне 90-х годов — мой сервис никто не купит. Поэтому мои ожидания более конкретны и ТЗ более детализировано.
В первом случае чем больше у разработчика пространства для манёвра — тем ниже риски у заказчика.
Во втором случае один неправильный манёвр разработчика может погубить весь бизнес.
Ну я выше уже ответил, что если интерфейс является важным требованием — значит включаем его в ТЗ.
Но из моей практики такие задачи были редки. Большая часть либо вообще не трогала пользовательский интерфейс, либо трогала, но каким он будет не важно, лижбы не 90е годы.
Противоречий у нас нет :)
Но из моей практики такие задачи были редки. Большая часть либо вообще не трогала пользовательский интерфейс, либо трогала, но каким он будет не важно, лижбы не 90е годы.
Противоречий у нас нет :)
Полностью согласен с этим. Хочу добавить, что в большинство задач первого случая не несут на себе бизнес роли, а создаются только для внутреннего пользования и т.п.
Вообще говоря, если обозначены только бизнес-цели, общие задачи и прочие функциональные спецификации, то вовсе не факт, что у заказчика ниже риски. Тот же интерфейс в стиле 90-х ему вполне могут выкатить. Или современный интерфейс, но на технологиях по сути осуществляющих «вендор-лок», создающих зависимость заказчика от конкретного подрядчика. Необязательно злонамеренно, например, просто кто-то фанатеет от малоизвестной технологии, либы, фрэймворка и т. п.
Немного поспорю :)
Во-первых, старинный интерфейс не будет особой проблемой, раз уж система для собственного пользования делается.
Во-вторых, при заказной разработке серьезной корпоративной системы, как показывает практика, всегда будет вендор-лок, даже если заказчик получит исходники с правами.
Во-первых, старинный интерфейс не будет особой проблемой, раз уж система для собственного пользования делается.
Во-вторых, при заказной разработке серьезной корпоративной системы, как показывает практика, всегда будет вендор-лок, даже если заказчик получит исходники с правами.
старинный интерфейс не будет особой проблемой
Производительность труда пользователей может оказаться сильно ниже расчетной, переобучивать придется тех, кто в прошлом тысячелетии ещё под стол ходил. Если у вас три-пять пользователей, то может и не особая проблема, а если сотни и тысячи?
как показывает практика
Вот прямо сейчас моя практика показывает обратное :) Хотя, конечно, из-за того что заказчик сменил подрядчика темпы изменений заметно снизились, но то, что продукт написан на хорошо знакомом фрэймворке очень сильно помогает не отвлекаться на инфраструктуру, а вникать (в основном)только в бизнес-логику.
Производительность труда пользователей может оказаться сильно ниже расчетной, переобучивать придется тех, кто в прошлом тысячелетии ещё под стол ходил.
Да верно, если пользователь работает в твоём приложении постоянно. Если же это какое-то вспомогательное ПО, то плохой UX выльется в потерю 5-10 минут рабочего времени в день. К тому же в корпоративе до сих пор много людей старшего возраста, которым такой интерфейс будет интуитивно понятнее.
Вот прямо сейчас моя практика показывает обратное :)
Это интересно. Я всегда считал, что такие случаи большая редкость. Впрочем наверняка у вас всё равно существенные трудозатраты уходят на разбор чужого кода, а местами и рефакторинг и пр. Следовательно для заказчика это дополнительные расходы. Следовательно определённый вендор-лок всё же имеет место. Нет?
Судя по описанию, исполнитель просто был выбран недостаточно квалифицированный. Для меня, как для разработчика (в первую очередь, фронтенд-разработчика), нет ничего лучше как можно более конкретных требований. А если заказчик сам был разработчиком, он прекрасно будет знать, что можно реализовать, что нельзя, а что можно, но в 3 раза дольше (дороже), чем если бы чуть-чуть упростить.
Отличная статья. Краткая и емкая — по существу. Спасибо!
Ну, делать выводы — это хорошо, но делать правильные выводы куда важнее.
Лично я думаю, что проблема не в том, что разработчики хотят делать как знают, переосмысливать поведение тех или иных элементов — они просто вынуждены это делать, т.к. предметную область они не хотят учить, ни хотят в неё вникать.
Когда мы ищем исполнителей мы с начало находим тех, у кого глаза загораются от нашей предметной области, людей которые захотят выучить бизнес до самых малейших деталей, и только потом переходим уже к технической части.
В сухом остатке получается: Разработчики хотят «высокие нагрузки», «круто», «биг дата», «стартап» и не хотят знать почему такие нагрузки, что на самом деле круто, так далее.
Хотя на самом деле, приложение которое написано учителем музыки с нарушением всего чего только можно, но РАБОТАЮЩЕЕ 10 ЛЕТ УЖЕ и приносящее миллионные доходы по сей день — ВОТ ЭТО КРУТО!
Лично я думаю, что проблема не в том, что разработчики хотят делать как знают, переосмысливать поведение тех или иных элементов — они просто вынуждены это делать, т.к. предметную область они не хотят учить, ни хотят в неё вникать.
Когда мы ищем исполнителей мы с начало находим тех, у кого глаза загораются от нашей предметной области, людей которые захотят выучить бизнес до самых малейших деталей, и только потом переходим уже к технической части.
В сухом остатке получается: Разработчики хотят «высокие нагрузки», «круто», «биг дата», «стартап» и не хотят знать почему такие нагрузки, что на самом деле круто, так далее.
Хотя на самом деле, приложение которое написано учителем музыки с нарушением всего чего только можно, но РАБОТАЮЩЕЕ 10 ЛЕТ УЖЕ и приносящее миллионные доходы по сей день — ВОТ ЭТО КРУТО!
Лично я думаю, что проблема не в том, что разработчики хотят делать как знают, переосмысливать поведение тех или иных элементов — они просто вынуждены это делать, т.к. предметную область они не хотят учить, ни хотят в неё вникать.
И такой момент был. Часто меня пытались убедить сделать какие-то фичи по-другому. К счастью у меня были готовые сценарии, объясняющие почему спроектировано именно так. Мы же не от балды всё рисовали :) Так что это не было существенной проблемой.
Противоречивые впечатления оставил Ваш пост. Я, честно говоря, никогда не видел, чтобы пространство для маневра хорошо сказывалось и для Заказчика и для Подрядчика. В этом случае, Подрядчик вынужден сам принимать решения по тому, что и как делать, и практически со 100% вероятностью на выходе будет не то, что ожидает Заказчик.
Мне ваш опыт видится в таком свете. Большинство российских компаний вообще плохо понимают ответственность подрядчика перед заказчиком, целиком сводя свою деятельность к тому, чтобы подписать акт сдачи-приемки. И, на моем опыте, зачастую ключевую роль в этом вопросе играет не качество продукта, а сколько Иван Иваныч с Иван Васьльичем водки выпили и мест посетили (каких уточнять не буду).
В вашем случае, Вы действительно были очень хорошим Заказчиком. Но вот выбор компании-подрядчика был, видимо, не очень удачен. Это была обычная среднестатистическая российская компания, от которой у иностранных Заказчиков очень рано появляются седые волосы.
Лично в моем опыте Подрядчика самым лучшим был проект, где ТЗ занимало 5 томов по 700 страниц с делением по дисциплинам, с прописыванием всего и вся. И таки это был немецкий Заказчик.
Мне ваш опыт видится в таком свете. Большинство российских компаний вообще плохо понимают ответственность подрядчика перед заказчиком, целиком сводя свою деятельность к тому, чтобы подписать акт сдачи-приемки. И, на моем опыте, зачастую ключевую роль в этом вопросе играет не качество продукта, а сколько Иван Иваныч с Иван Васьльичем водки выпили и мест посетили (каких уточнять не буду).
В вашем случае, Вы действительно были очень хорошим Заказчиком. Но вот выбор компании-подрядчика был, видимо, не очень удачен. Это была обычная среднестатистическая российская компания, от которой у иностранных Заказчиков очень рано появляются седые волосы.
Лично в моем опыте Подрядчика самым лучшим был проект, где ТЗ занимало 5 томов по 700 страниц с делением по дисциплинам, с прописыванием всего и вся. И таки это был немецкий Заказчик.
О каких суммах шла речь в том «немецком контракте»?
Лично в моем опыте Подрядчика самым лучшим был проект, где ТЗ занимало 5 томов по 700 страниц с делением по дисциплинам, с прописыванием всего и вся. И таки это был немецкий Заказчик.
Как интересно! А можно поподробнее? Что там имело основной вес? Описание предметной области? Бесконечные UML-диаграммы? Мокапы?
Блин, это же получается надо в календарном плане отделно прописывать — Этап 1. Изучение ТЗ. 1 месяц. $10 000. :)
Это проект не из It-отрасли, а, скорее, из проектирования под строительство. Поэтому, например, один из томов детально описывал все процедуры, которые только могут понадобиться при реализации, другой определял форматы, параметры передачи данных, структуру документов, отдельным томом шла безопасность — вплоть до регламентирования пользования мобильной связью. Изучение ТЗ, к сожалению, пока в смету никто не вставляет :)
Суть одна. При таком дотошном подходе у Подрядчика довольно мало возможностей для творчества, но при этом есть полная ясность, что хорошо, а что плохо. Что будет принято, что необходимо переделать даже без участия Заказчика.
Суть одна. При таком дотошном подходе у Подрядчика довольно мало возможностей для творчества, но при этом есть полная ясность, что хорошо, а что плохо. Что будет принято, что необходимо переделать даже без участия Заказчика.
Изучение ТЗ — этап номер 0. И этот этап должен быть проведён до того как подрядчик взялся за работу. Вот как раз недостаточное внимание к этому этапу и приводит зачастую ко многим проблемам.
Такое ТЗ можно написать только для проекта, который реализуется не первый и не второй раз, например, для строительства типового многоэтажного дома — важно четко выполнить задания, который точно правильные и в нужном порядке.
Разработка новой системы — процесс творческий, вы эту конкретную систему пишете впервые, и как вы это полностью формализуете? Откуда вы будете знать, что ваш план хорош? Шаг 1: начинаем разрабатывать форму №4768; Шаг 2: получаем шедевр?
Один умный чувак сказал (или даже почти доказал?), что усилия по созданию полного ТЗ примерно эквивалентны собственно реализации системы, и мне кажется, он был прав.
Разработка новой системы — процесс творческий, вы эту конкретную систему пишете впервые, и как вы это полностью формализуете? Откуда вы будете знать, что ваш план хорош? Шаг 1: начинаем разрабатывать форму №4768; Шаг 2: получаем шедевр?
Один умный чувак сказал (или даже почти доказал?), что усилия по созданию полного ТЗ примерно эквивалентны собственно реализации системы, и мне кажется, он был прав.
Такая-же фигня, я им в начале проекта бью себя в грудь — «Да я рубаха-парень, такой же как вы был программист», а они меня к концу «злым следователем» кличут.
Проектирование (функциональность, интерфейсы, спецификации и т. п.) с разработкой (технологии, архитектура, собственно код) разделять, по-моему, можно, но и заказчик, и подрядчик должны мало того, что быть компетентными в своих областях ответственности, но и быть готовыми адекватно коммуницировать — подрядчику аргументированно и конструктивно критиковать, а заказчику серьезно к критике относиться. В конце концов у заказчика глаз может быть замылен, а спорные моменты в проекте будут почти наверняка.
Ну а первые два пункта говорят, да, скорее всего о недостаточной квалификации подрядчика. Тянуть время по надуманным предлогам и договариваться о закрытие глаз на баги как-то непрофессионально. Куда эффективнее обычно сказать «тут мы профэйлили и не успеваем, тут не можем реалистично оценить время» и «этот баг к релизу исправить не получится — или откладываем релиз, или релизимся с багом».
Ну а первые два пункта говорят, да, скорее всего о недостаточной квалификации подрядчика. Тянуть время по надуманным предлогам и договариваться о закрытие глаз на баги как-то непрофессионально. Куда эффективнее обычно сказать «тут мы профэйлили и не успеваем, тут не можем реалистично оценить время» и «этот баг к релизу исправить не получится — или откладываем релиз, или релизимся с багом».
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать.
Прям ОЧЕНЬ не согласен, как по мне, чем конкретнее задача, тем быстрее я ее сделаю и заказчика дергать не буду и сам не буду вертеться в сомнениях. А когда заказчик предоставляет готовые части, так это совсем круто, да у меня могут возникнуть вопросы и замечания, но уладить их можно в любой момент если заказчик на связи. Вплоть до редакции кода и присланных файлов.
Очень хорошо написано, и главное в точку. Многие описания неадекватных заказчиков — это то, с чем мне приходиться иметь дело непосредственно сейчас.
Я несколько раз сталкивался с ситуацией когда «заказчик точно знает что хочет и уже нарисовал UI». Это не работает. Причина банальна — у исполнителей просто может быть немного другое видение и другие подходы, и не всегда эти подходы будут совпадать. Мы недавно разрабатывали проект для компании которая постоянно настаивала на том что они до детаей знают как _это_ должно работать, но на деле, оказалось что многие бизнес процессы были неоптимальны. Закачики «знали досконально как» в рамках того процесса, который у них уже построен, но при адекватном рассмотрении и совместном планировании многие бизнес процессы реально упростились, выдав немного другой результат чем был прорисован на начальных экранах, но в общем к взаимной выгоде как заказчика так и нашей. Хорошее ПО рождается в процессе взаимного обмена знаниями. Просто «закодировать» экраны и бизнес логику — часто скучно, и главное — не несёт позитивной нагнузки. Тупые кодеры скорее всего не въедут в смысл задачи и это послужит почвой для массы недоработок в процессе, а умные кодеры просто не возьмуться за задачку где «всё уже решено».
Я несколько раз сталкивался с ситуацией когда «заказчик точно знает что хочет и уже нарисовал UI». Это не работает. Причина банальна — у исполнителей просто может быть немного другое видение и другие подходы, и не всегда эти подходы будут совпадать. Мы недавно разрабатывали проект для компании которая постоянно настаивала на том что они до детаей знают как _это_ должно работать, но на деле, оказалось что многие бизнес процессы были неоптимальны. Закачики «знали досконально как» в рамках того процесса, который у них уже построен, но при адекватном рассмотрении и совместном планировании многие бизнес процессы реально упростились, выдав немного другой результат чем был прорисован на начальных экранах, но в общем к взаимной выгоде как заказчика так и нашей. Хорошее ПО рождается в процессе взаимного обмена знаниями. Просто «закодировать» экраны и бизнес логику — часто скучно, и главное — не несёт позитивной нагнузки. Тупые кодеры скорее всего не въедут в смысл задачи и это послужит почвой для массы недоработок в процессе, а умные кодеры просто не возьмуться за задачку где «всё уже решено».
Ваш заказчик был конечным пользователем? Заказывал ПО для своего внутреннего пользования?
Да. По сути — они работают в своей области более 15ти лет, перепробовали кучу ПО, решили писать своё. Как смогли нарисовали экраны и выдали нам полную спецификацию (говорили что знают всё на 100%). Но по сути, они не программисты, а продвинутые пользователи. Т е многие вещей, из за того что другие программы на аналогичную тему были не продуманы до конца, они не видели. В процессе работы предоставленные нам UI mockups сработали против проекта — так как вначале нас «нагнули» на то чтобы мы сделали «как они хотят» 1:1, а потом уже, когда к нам сформировался кредит доверия, мы постепенно вывели систему на нормальные рельсы, упростив и выбросив многие ненужные сложности. Т е на первом этапе работ, во время «сработки» были серьёзные проблемы. А сейчас всё наоборот — любые фичи и дополнения _вначале_ обсуждаются, думаем есть ли другие варианты (мозговой штурм) и потом уже принимаем совместно созданный дизайн в разработку.
Не могу согласиться с выводами
ИМО вам попался не самый квалифицированный разработчик, потому что сделать даже очень сложный код быстрее и менее геморно чем методом проб и переделок сделать как это «видит» заказчик. Дали подробное ТЗ — уже хорошо, дали сверстанный html с подробным описанием — сиди и ваяй. По мне идеальный вариант, если знаешь что и как делается.
Но в некоторых частностях я могу согласиться, например сторонний разработчик — это еще и другой опыт и бывает что свежий взгляд, пусть даже и не профессиональный, дает оригинальное решение. Поэтому какая-то свобода — это хорошо. Но я также как и выше не могу не согласиться что исполнителя никто не ограничивает предложить другие варианты в реализации. И идеальный Заказчик адекватно оценит и аргументированно откажется или примет изменения.
Но в принципе перед началом работы очень хорошо бы проговорить ТЗ, что бы мало того что не осталось вопросов по нему, но и Исполнитель воспринял идеи, воплощенные в ТЗ. И приняв их, воплощал бы их в коде, как уже свои.
ИМО вам попался не самый квалифицированный разработчик, потому что сделать даже очень сложный код быстрее и менее геморно чем методом проб и переделок сделать как это «видит» заказчик. Дали подробное ТЗ — уже хорошо, дали сверстанный html с подробным описанием — сиди и ваяй. По мне идеальный вариант, если знаешь что и как делается.
Но в некоторых частностях я могу согласиться, например сторонний разработчик — это еще и другой опыт и бывает что свежий взгляд, пусть даже и не профессиональный, дает оригинальное решение. Поэтому какая-то свобода — это хорошо. Но я также как и выше не могу не согласиться что исполнителя никто не ограничивает предложить другие варианты в реализации. И идеальный Заказчик адекватно оценит и аргументированно откажется или примет изменения.
Но в принципе перед началом работы очень хорошо бы проговорить ТЗ, что бы мало того что не осталось вопросов по нему, но и Исполнитель воспринял идеи, воплощенные в ТЗ. И приняв их, воплощал бы их в коде, как уже свои.
ИМО вам попался не самый квалифицированный разработчик
Ну квалификация любого разработчика имеет свои ограничения. Просто получилось так, что мы проектировали рассчитывая на супер-пупер-мега профи. А работать пришлось с обычными ребятами среднего уровня. А будь у нас требования не столь детализированы, они какие-то вещи опустили бы до своего уровня. Да, местами получилось бы не очень круто… но получилось бы :)
Почитав статью у меня родился портрет идеального заказчика.
Итак, поехали, «идеальный заказчик» в оутсорсе это тот который:
Итак, поехали, «идеальный заказчик» в оутсорсе это тот который:
- осознает что выстреливает всего 1% проектов, поэтому изначально готов к тому что вероятность успеха 1%
- тратит на проект не свои деньги
- многие вопросы решает «на усмотрение исполнителя»
- готов к тому что заказчик закладывает фундамент для Проекта 2.0 и делает все основательно «по-уму», поэтому сроки немного переносятся.
- с понимаем относиться к тому что в IT к дедлайну надо мысленно прибавить +50% времени.
- уверен в том что подрядчик максимально эффективно пытается использовать оплаченное время разработки проекта
- уверен: именно над его проектом будут работать только самые лучшие/опытные программисты подрядчика
- готов подписать акты даже с мелкими багами, понимая что идеального кода не существует, и что у подрядчика просто сейчас идет поиск лучшего решения для устранения багов.
>детали нуждаются в дополнительных пояснениях или примерах и получить таким образом дополнительное время
Какое время имеется в виду? Лишний раз объяснить то что ты хочешь-надо не особо много времени вроде, особенно если ты все время доступен для команды разработки
Какое время имеется в виду? Лишний раз объяснить то что ты хочешь-надо не особо много времени вроде, особенно если ты все время доступен для команды разработки
Имеется в виду старый и проверенный трюк — найти особо сложное место, какое-то запутанное правило, например, и сделать вид, что вообще не вкурил как оно должно быть.
Просишь детализировать это требование, желательно с примерами и просчетом вариантов. Отображение времени в разных таймзонах, например. А пока заказчик это делает — срочно что-то допиливаешь. Так можно выиграть 1-2 дня :)
Просишь детализировать это требование, желательно с примерами и просчетом вариантов. Отображение времени в разных таймзонах, например. А пока заказчик это делает — срочно что-то допиливаешь. Так можно выиграть 1-2 дня :)
Не понял, как вы пришли к выводу, что такой подход неправильный.
Вы результат получили? В срок? С нужным качеством?
Подрядчик знал, на что шёл? Вы свои условия выполнили?
Вы результат получили? В срок? С нужным качеством?
Подрядчик знал, на что шёл? Вы свои условия выполнили?
Не существует идеального заказчика и я не вижу ни одного повода для ваших переживаний, ИМХО:
1) Вы платите деньги за тот продукт, который вы хотите получить.
2) Если вы платите хорошо, вы тем более имеете право получить то, что вы хотите.
3) Конечный разработчик (я говорю об организации) — формальный исполнитель. Они знали на что шли, когда подписывали контракт (если он был). Их основная задача — удовлетворить ваши требования и получить деньги. Если они не могу этого сделать — вам стоит подумать о другом исполнителе.
> Идеальный заказчик не должен в деталях прописывать поведение каждого контрола.
Почему нет? Если объем системы таков, что вы можете все сами проконтролировать + у вас есть ресурс по времени и деньгам, то зачем идти на компромисс? Вы платите — они делают. Какая вам разница, что происходит за кадром?
1) Вы платите деньги за тот продукт, который вы хотите получить.
2) Если вы платите хорошо, вы тем более имеете право получить то, что вы хотите.
3) Конечный разработчик (я говорю об организации) — формальный исполнитель. Они знали на что шли, когда подписывали контракт (если он был). Их основная задача — удовлетворить ваши требования и получить деньги. Если они не могу этого сделать — вам стоит подумать о другом исполнителе.
> Идеальный заказчик не должен в деталях прописывать поведение каждого контрола.
Почему нет? Если объем системы таков, что вы можете все сами проконтролировать + у вас есть ресурс по времени и деньгам, то зачем идти на компромисс? Вы платите — они делают. Какая вам разница, что происходит за кадром?
Почему нет? Если объем системы таков, что вы можете все сами проконтролировать + у вас есть ресурс по времени и деньгам, то зачем идти на компромисс? Вы платите — они делают. Какая вам разница, что происходит за кадром?
В комментах выше мы пришли к выводу, что проектировать надо с учетом квалификации исполнителя. Чем абстрактнее требования, тем больше у исполнителя возможностей сделать что-то «попроще» скажем так. Чрезмерная детализация снижает возможность такого манёвра.
Хорошая статья, хотел уточнить один момент:
Случай 1:
Я получаю от заказчика сверстанный макет сайта с просьбой натянуть его на CMS или использовать CMF, но дело в том, что код(html) сверстанный по дизайну заказчика ни одним из компонентов(СMS,CMF) не формируется в том виде в котором хочет заказчик. Заказчик требует, что бы полученный код(html) был точно таким же как в присланном макете. Соответственно, мне надо затратить время на написание модуля для формирования аутентичного результата.
Случай 2:
В присланном макете есть сверстанный блок с формой подписки, а в ТЗ написано, что будет использоваться сторонний блок кода с стороннего сервиса(subscribe.ru или др.), но верстальщик сделал макет по своему. Соответственно имеем, что макет содержит одно(верстка html), а сторонний блок кода формирует совершенно другое, а задача сделать как в макете. Опять грабли с затратой времени на изменение внешнего блока формы и придания нужного функционала, что влечет за собой затраты времени.
Случай 3:
Использование динамической загрузки содержимого страницы через AJAX. Не столь сложная задача, но требующая довольно много рутинной работы, и это так же затраты времени.
Все эти случаи объединяет один фактор — кроме данного проекта я не смогу нигде повторно использовать полученный в результате код.
Это можно где-то сравнить с формированием попиксельной верстки.
Я Вас правильно понял?
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать. А мои требования были настолько конкретизированы, что разработчик полностью лишался пространства для манёвра. И если он не мог что-то реализовать (особенно на фронт-енде), то у него просто не было возможности сделать по-другому – сделать так, как умеет. В результате любую проблему приходилось решать самым сложным способом, потому что обходной путь всегда был отрезан.
Случай 1:
Я получаю от заказчика сверстанный макет сайта с просьбой натянуть его на CMS или использовать CMF, но дело в том, что код(html) сверстанный по дизайну заказчика ни одним из компонентов(СMS,CMF) не формируется в том виде в котором хочет заказчик. Заказчик требует, что бы полученный код(html) был точно таким же как в присланном макете. Соответственно, мне надо затратить время на написание модуля для формирования аутентичного результата.
Случай 2:
В присланном макете есть сверстанный блок с формой подписки, а в ТЗ написано, что будет использоваться сторонний блок кода с стороннего сервиса(subscribe.ru или др.), но верстальщик сделал макет по своему. Соответственно имеем, что макет содержит одно(верстка html), а сторонний блок кода формирует совершенно другое, а задача сделать как в макете. Опять грабли с затратой времени на изменение внешнего блока формы и придания нужного функционала, что влечет за собой затраты времени.
Случай 3:
Использование динамической загрузки содержимого страницы через AJAX. Не столь сложная задача, но требующая довольно много рутинной работы, и это так же затраты времени.
Все эти случаи объединяет один фактор — кроме данного проекта я не смогу нигде повторно использовать полученный в результате код.
Это можно где-то сравнить с формированием попиксельной верстки.
Я Вас правильно понял?
Все очень сильно зависит от индивидуальностей той или иной команды, программиста, дизайнера.
Одна и та же работа двумя разными программистами не будет выполнена одинаково.
В вашем случае считаю что произошел сбой именно в компетенции исполнителя.
Одна и та же работа двумя разными программистами не будет выполнена одинаково.
В вашем случае считаю что произошел сбой именно в компетенции исполнителя.
Блин, когда всё отрисовано как у вас, наоборот круто.
Не парьтесь! Вам просто не повезло с исполнителем и всё! Продолжайте ставить задачи в том же духе! В конце концов они (задачи) именно ваши и отдавать их на откуп исполнителю не правильно, особенно если у вас есть свое четкое видение проекта. Тут, как говорится, любой каприз за ваши деньги…
Странные выводы у Вас. У меня все наоборот — когда встретил такого заказчика, я полюбил свою работу на 50% больше. Я понял, что мне намного приятнее думать о том, какой паттерн применить и т.п., чем думать о виде попапов и т.д.
По мере прочтения длинного списка психопатов, с которыми вам доводилось работать, в голове моей все сочнее набухал вопрос: «Зачем же себя так мучать?». Вторая часть эпоса продолжила начатое.
Главный вывод, на мой взгляд, гораздо проще: «Если человеку нравится мучаться. Он будет это делать в любой роли: и будучи исполнителем, и будучи заказчиком».
Главный вывод, на мой взгляд, гораздо проще: «Если человеку нравится мучаться. Он будет это делать в любой роли: и будучи исполнителем, и будучи заказчиком».
Могу за автора ответить на ваш главный вопрос: потому что это средненькая аутсорс-конторка, которая берется за все проекты, которые хоть как-то можно сделать и хоть как-то получить прибыль. А что, есть такой сегмент рынка, и кому-то эту работу надо делать.
Более того, я не раз замечал что самые лучшие заказчики аутсорсят в Индию, потому что по таким спекам, как описывает автор, даже code monkey сделает все нормально.
Более того, я не раз замечал что самые лучшие заказчики аутсорсят в Индию, потому что по таким спекам, как описывает автор, даже code monkey сделает все нормально.
Когда ты очењ молодой, но уже умеешь работать руками. Когда ты уже умеешь работать руками, но еще не понял, насколько важно умение продавать результат твоих технических талантов. Когда ты еще работаешь на свое доброе имя, а не имя работает на тебя…
Как минимум, во всех этих случаях чаще всего приходится постоянно работать с кошмарными $%даками. Это тот самый опыт, который «сын ошибок трудных». Пока мне не исполнилось 23 года я очень часто работал с феерическими придурками просто потому что солидные заказчики не были готовы мне (человеку со стороны, без репутации) предложить нормальные дењги, а мелкие заказчики зачастую представляли собой весь тот паноптикум, который описал автор.
Ну а еще есть случай, когда тебе сулят за твою работу реально большой гонорар (превышающий рыночное предложение раза в 2-3) потому что в ТЗ написано «принеси то, чего не знаю сам». И если маржа покрывает риски — почему бы с такими чудаками не работать?
Как минимум, во всех этих случаях чаще всего приходится постоянно работать с кошмарными $%даками. Это тот самый опыт, который «сын ошибок трудных». Пока мне не исполнилось 23 года я очень часто работал с феерическими придурками просто потому что солидные заказчики не были готовы мне (человеку со стороны, без репутации) предложить нормальные дењги, а мелкие заказчики зачастую представляли собой весь тот паноптикум, который описал автор.
Ну а еще есть случай, когда тебе сулят за твою работу реально большой гонорар (превышающий рыночное предложение раза в 2-3) потому что в ТЗ написано «принеси то, чего не знаю сам». И если маржа покрывает риски — почему бы с такими чудаками не работать?
Это вопрос из сферы вкусовщины. Автору топика нравится вот себя мучать. Правда.
Эрик Берн об этом книгу целую написал, где все очень ясно и занудно расписано. Нравится страдать – играйте в страдания; нравится, чтобы вас жалели, например, страдайте публично; нравится думать, что ваши деньги даются вам тяжело, работайте неэффективно, но целыми ночами и без выходных; нравится считать программирование адски сложным – собирайте сайты на ассемблере и т.д. Все это вопрос игры, в которую вы хотите поиграть с вашим окружением.
То есть на ваш вопрос: «А почему бы не ...?», – я отвечу: «Это не моя игра». Мне не в кайф работать с мудаками, какие бы деньги они не предлагали.
Эрик Берн об этом книгу целую написал, где все очень ясно и занудно расписано. Нравится страдать – играйте в страдания; нравится, чтобы вас жалели, например, страдайте публично; нравится думать, что ваши деньги даются вам тяжело, работайте неэффективно, но целыми ночами и без выходных; нравится считать программирование адски сложным – собирайте сайты на ассемблере и т.д. Все это вопрос игры, в которую вы хотите поиграть с вашим окружением.
То есть на ваш вопрос: «А почему бы не ...?», – я отвечу: «Это не моя игра». Мне не в кайф работать с мудаками, какие бы деньги они не предлагали.
Проблема в том, что «идеальный заказчик» и «желанный заказчик» — разные вещи.
Возможно вы и были идеальными заказчиками. С идеальными ТЗ и четкими требованиями. Вот только работать с таким заказчиком сложно: он не прощает ошибок или халтуры.
Если заказчик толком не знает, чего он хочет, разработчик может сделать то, что он умеет, и как он умеет. Потом убедить заказчика в том, что именно это ему нужно.
Так что «идеальный заказчик» — как строгий учитель. Он, конечно же, идеален, но любить его за это не будут. Работать с ним приходится на его уровне.
«Желанный заказчик» — как добрый учитель. Вряд ли чему-то научит, ставя даром пятерки. Но он-то и есть эталон любимца: как в школе, так и в бизнесе.
Возможно вы и были идеальными заказчиками. С идеальными ТЗ и четкими требованиями. Вот только работать с таким заказчиком сложно: он не прощает ошибок или халтуры.
Если заказчик толком не знает, чего он хочет, разработчик может сделать то, что он умеет, и как он умеет. Потом убедить заказчика в том, что именно это ему нужно.
Так что «идеальный заказчик» — как строгий учитель. Он, конечно же, идеален, но любить его за это не будут. Работать с ним приходится на его уровне.
«Желанный заказчик» — как добрый учитель. Вряд ли чему-то научит, ставя даром пятерки. Но он-то и есть эталон любимца: как в школе, так и в бизнесе.
Вот оно! Именно то, что я пытался сформулировать, но никак не находил правильных слов. Отлично сказано!
Мне кажется вам просто не повезло с исполнителем. Мне вот например нравится работать «на уровне», когда все понятно, когда получается хороший продукт, когда я сам доволен своей работой. А этого без конкретики и обоюдного четкого понимания цели и путей достижения этой цели — не выйдет.
Заказчики, которые не знают чего хотят, и их потом нужно убеждать, что все замечательно — ужс.
Впрочем заказчики, которые знают чего хотят, но хотят какой то невообразимый кошмар — еще хуже…
Заказчики, которые не знают чего хотят, и их потом нужно убеждать, что все замечательно — ужс.
Впрочем заказчики, которые знают чего хотят, но хотят какой то невообразимый кошмар — еще хуже…
а зачем вам нужно быть идеальным заказчиком? Ведь идеальный заказчик, на самом деле, — это тот, кто даст много-много денег за какую-то ерунду, которую ваш стажер сделает в перерыве между матчами в контру.
Я всегда был сложным заказчиком (надеюсь), что значит, что за свои деньги (ну, не свои, а компании) старался добиться максимального результата — и считаю, что это правильно. Все же логичнее делать счастливым себя, а не исполнителя. Если исполнитель очень доволен — вероятно, вы переплатили.
Я всегда был сложным заказчиком (надеюсь), что значит, что за свои деньги (ну, не свои, а компании) старался добиться максимального результата — и считаю, что это правильно. Все же логичнее делать счастливым себя, а не исполнителя. Если исполнитель очень доволен — вероятно, вы переплатили.
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать.
Уверен что выше в комментариях про это уже написали и возможно не раз, но это очень, очень странное утверждение.
Все с точностью наоборот. В рамках работы фронтенда обычно не составляет никакого труда реализовать любую конкретику, если она вообще в принципе реализуема. А вот когда задача абстрактна то это как минимум добавляет работы по придумыванию того, как же оно должно работать.
Не говоря уж о том, что потом ВСЕГДА выясняется, что заказчик представлял себе это все совершенно иначе и приходится переделывать. Раза три, потому что конкретики так и не появляется.
Реализовать любую конкретику… Ох, не соглашусь. Если речь заходит, к примеру, о сторонних компонентах, начинаются огромные проблемы с тем, чтобы все заработало именно так, как планировалось. Одним словом, нарисовать можно что угодно, а вот кастомизировать сторонние компоненты под нарисованное иногда бывает очень сложно.
Хм, ну может я чего-то не знаю. Можете пример какой-то привести?
Как то я не припомню чтобы во фронтенде были задачи которые никак не реализовать.
Бывают конечно сложные вещи, например если 3д нужно и заявлена поддержка IE) Но и это в принципе реализуется.
Тем более, что автор вроде как разбирается в предметной области и понимает, что можно реализовать, а что нельзя(или неоправданно долго).
Возможно в сфере мобильной разработки с этим не так и тогда я не прав. Маловато в ней опыта, чтобы судить.
Как то я не припомню чтобы во фронтенде были задачи которые никак не реализовать.
Бывают конечно сложные вещи, например если 3д нужно и заявлена поддержка IE) Но и это в принципе реализуется.
Тем более, что автор вроде как разбирается в предметной области и понимает, что можно реализовать, а что нельзя(или неоправданно долго).
Возможно в сфере мобильной разработки с этим не так и тогда я не прав. Маловато в ней опыта, чтобы судить.
Конкретика — это набор условий. Условия, которые выглядят логично вначале, могут приводить к непредсказуемым результатам впоследствии.
Ну, ОК, пример. Делаем фронтенд. Условия: макет страницы, определенная библиотека компонентов, определенная функциональность, поддержка определенных браузеров, определенный бюджет и дедлайн. Нормальные стартовые условия, так ведь?
Начинаем делать. Оказывается, некоторые части выбранных компонентов не поддаются кастомизации на нужном уровне. В разных браузерах (привет, ИЕ!) не вся функциональность может быть воспроизведена корректно. Приходится либо лезть глубоко внутрь и лечить баги самостоятельно (выходим за рамки бюджета), либо ждать, пока разработчик компонентов выкатит новую версию (выходим за рамки дедлайна), либо менять требования к дизайну и функциональности.
Ну, ОК, пример. Делаем фронтенд. Условия: макет страницы, определенная библиотека компонентов, определенная функциональность, поддержка определенных браузеров, определенный бюджет и дедлайн. Нормальные стартовые условия, так ведь?
Начинаем делать. Оказывается, некоторые части выбранных компонентов не поддаются кастомизации на нужном уровне. В разных браузерах (привет, ИЕ!) не вся функциональность может быть воспроизведена корректно. Приходится либо лезть глубоко внутрь и лечить баги самостоятельно (выходим за рамки бюджета), либо ждать, пока разработчик компонентов выкатит новую версию (выходим за рамки дедлайна), либо менять требования к дизайну и функциональности.
Но это ведь в данном случае не проблема разработчика вовсе. Если условия ставит заказчик и при этом в рамках этих условий задача не реализуема(в разумные сроки) — это вина заказчика.
Конечно в реальном мире это все равно будет вина разработчика, но у нас ведь заказчик предполагается «идеальным». Т.е. он в теме происходящего и понимает, что по факту это прокол на этапе планирования, а этап планирования лежит на нем.
Вообще это все по опыту бывает трех видов.
Заказчик ничего не знает точно, в результате мы можем делать как угодно, но потом долго развлекаемся с тем, что в середине проекта оказывается, что нужен вовсе не сайт-визитка, а интернет-магазин и онлайн-шашки. И вот эти вот попапы должны выпадать не сверху-вниз, а снизу-вверх. Нет-нет, все же сверху-вниз. Нет знаете, давайте тут вообще будет не попап, а как будто оно выпрыгивает!
Вариант второй, когда заказчик думает, что он точно знает чего хочет. И четко оговаривает условия. И да-да, он «тоже программист». И ничерта в этом всем не смыслит.
Вот тут начинается веселье, когда вам нужно на яваскрипте сделать 3д-шутер в баннере и чтоб в IE5 работало.
На мой взгляд это самый худший вариант. От таких заказов лучше просто сразу отказываться т.к. переубедить человека что нужно использовать другие технологии — невозможно, а работать с предлагаемыми — еще более невозможно.
И третий вариант, когда заказчик четко знает чего и как хочет. Крайне редко такое бывает. Обычно в таких случаях особых проблем нет т.к. он знает не только чего он хочет но и примерно представляет что можно сделать, что нельзя, что нельзя за разумное время. При описанных вами проблемах с таким заказчиком обычно можно их обсудить и найти пути решения. Заменить компоненту на другую. Заделать дыру хаком, пока не появится фикс. Реализовать этот функционал на базе чего-то другого. То или иное решение есть практически всегда.
Такой заказчик несравнимо приятнее других. Намного лучше и удобней работать когда все понятно и есть уверенность в завтрашнем дне.
Да, эти типы заказчиков это конечно не типы, а спектр.
Конечно в реальном мире это все равно будет вина разработчика, но у нас ведь заказчик предполагается «идеальным». Т.е. он в теме происходящего и понимает, что по факту это прокол на этапе планирования, а этап планирования лежит на нем.
Вообще это все по опыту бывает трех видов.
Заказчик ничего не знает точно, в результате мы можем делать как угодно, но потом долго развлекаемся с тем, что в середине проекта оказывается, что нужен вовсе не сайт-визитка, а интернет-магазин и онлайн-шашки. И вот эти вот попапы должны выпадать не сверху-вниз, а снизу-вверх. Нет-нет, все же сверху-вниз. Нет знаете, давайте тут вообще будет не попап, а как будто оно выпрыгивает!
Вариант второй, когда заказчик думает, что он точно знает чего хочет. И четко оговаривает условия. И да-да, он «тоже программист». И ничерта в этом всем не смыслит.
Вот тут начинается веселье, когда вам нужно на яваскрипте сделать 3д-шутер в баннере и чтоб в IE5 работало.
На мой взгляд это самый худший вариант. От таких заказов лучше просто сразу отказываться т.к. переубедить человека что нужно использовать другие технологии — невозможно, а работать с предлагаемыми — еще более невозможно.
И третий вариант, когда заказчик четко знает чего и как хочет. Крайне редко такое бывает. Обычно в таких случаях особых проблем нет т.к. он знает не только чего он хочет но и примерно представляет что можно сделать, что нельзя, что нельзя за разумное время. При описанных вами проблемах с таким заказчиком обычно можно их обсудить и найти пути решения. Заменить компоненту на другую. Заделать дыру хаком, пока не появится фикс. Реализовать этот функционал на базе чего-то другого. То или иное решение есть практически всегда.
Такой заказчик несравнимо приятнее других. Намного лучше и удобней работать когда все понятно и есть уверенность в завтрашнем дне.
Да, эти типы заказчиков это конечно не типы, а спектр.
Приложение хоть получилось каким ожидали?
Спасибо за интересно написанную статью. Есть саспенс. Я поначалу даже удивился наивному рассказу (мысленно возвращаясь в свои 22-24 года, когда сам по юности сталкивался с тем же самым), а потом, перескакивая через скучные абзацы дошел до слов «Во-первых, я слишком хорошо ориентировался в требованиях...»
Автор, ты крутой. Это, наверное, лучшая статья на Хабре про управление проектами как минимум за полгода, если не бољше. И обсуждение тоже интересное.
Автор, ты крутой. Это, наверное, лучшая статья на Хабре про управление проектами как минимум за полгода, если не бољше. И обсуждение тоже интересное.
автрр, спасибо что помог мне выразить и понять мои собственные мысли :)
Похоже, что вы работали с этим человеком так же, как вы работаете с членами своей команды. В то же время вы намеренно взяли его с аутсорса, чтобы не нужно было обучать внутренним процессам и методам коммуникации. Уже в этом видится некоторое противоречие. Это оттягощалось тем, что поддерживать контакт с человеком, работающим удаленно, сложнее, чем с ним же, сидящим рядом в офисе. В общем, похоже что сэкономить на обучении не получилось.
Просто взгляд со стороны.
Просто взгляд со стороны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я был идеальным заказчиком