Я писал не про процесс в самой компании, как постановка задач и прочее, а про то как та или иная функциональность укладывается в общий процесс разработки.
То что вы пишете более относится непосредственно к управлению проектом, т.е. людьми, их коммуникациями. А это очень сильно зависит от проектной модели. Мне довелось поработать в RUP образной модели и в Scrum образной. И культура документирования, работы с требованиями и пр очень сильно отличались.
А вот именно то, как фичи ложаться в общей процесс создания итогового продукта было очень схоже. Я в основном именно про это писал.
пайплайн — pipeline — водопровод.
В проекте это путь идеи от момента ее высказывания, до момента когда сущность олицетворяющая идею, появляется в игре. В том или ином виде сюда включены все тулы, системы контроля версий, билд система и пр. Конкретика зависит от проекта.
пайплайн — pipeline — водопровод.
В проекте это путь идеи от момента ее высказывания, до момента когда сущность олицетворяющая идею, появляется в игре. В том или ином виде сюда включены все тулы, системы контроля версий, билд система и пр. Конкретика зависит от проекта.
Вопрос был в том, на кого работает человек составляющий т.з.
Если он сотрудник клиента (маркетолог, тех специалист или еще кто) то самое логичное и правильное вести диалог с ним. Т.к. в вашем случае это ваш сотрудник, то действительно проблемно объяснить причину того или иного дизайнерского решения.
-и этому перечат не документы, а здравый смысл
Чей здравый смысл? Ваш, или вашего клиента? Вы уверены, что правильно оцениваете целевую аудиторию сайта? Может это жены друзей клиента которые просто обожают такой декор?
У вас есть только один вариант. Привести здравый смысл клиента и ваш к общему знаменателю. Вообще надо говорить на том языке на котором разговаривают с вами.
Зачастую при таких спорах тех специалисты исполнителя говорят на языке который не понятен заказчику. Потом оба расходятся в полной уверенности собственной правоты и дебилизма собеседника.
Убедите клиента, что «бабла такой сайт не будет зарабатывать ну ваааще» и «реально такое изменение уменьшит ваш доход»
Только надо все аргументировать, а не говорить что ваша Жена не фига не смыслит в сайтах.
Понятие хорошего сайта формализуется в контракте/заказе/тз.
Если оно противоречит вашему чувству прекрасного и принципам по которым отбираете сайты в портфолио, то это лично ваши проблемы.
Сайт, который не удовлетворят тому что описано в контракте/заказе/тз — плохой сайт.
Клиент всегда прав, потому, что он платит за сделанную работу.
Его надо убеждать или делать как он скажет.
Вообще понятие хорошего дизайна эксплуатируемое в статье, очень сильно завязано на ответы на вопросник, который приведен в конце. Без него непонятно как вообще можно говорить и конкретном дизайне.
Есть еще один интересный момент.
Что делать, когда команда уже наполнена мотивированными людьми. Когда они сами хотят брать на себя ответственность. Надо решать, кому и что давать.
Ведь в проекте всегда есть интересные места и не очень.
Как сохранить мотивацию тех, кто получил неинтересное направление и т.д.
То что вы пишете более относится непосредственно к управлению проектом, т.е. людьми, их коммуникациями. А это очень сильно зависит от проектной модели. Мне довелось поработать в RUP образной модели и в Scrum образной. И культура документирования, работы с требованиями и пр очень сильно отличались.
А вот именно то, как фичи ложаться в общей процесс создания итогового продукта было очень схоже. Я в основном именно про это писал.
В проекте это путь идеи от момента ее высказывания, до момента когда сущность олицетворяющая идею, появляется в игре. В том или ином виде сюда включены все тулы, системы контроля версий, билд система и пр. Конкретика зависит от проекта.
В проекте это путь идеи от момента ее высказывания, до момента когда сущность олицетворяющая идею, появляется в игре. В том или ином виде сюда включены все тулы, системы контроля версий, билд система и пр. Конкретика зависит от проекта.
Именно так.
Обсуждение мелких деталей с заказчиком вполне нормально для разработки чего угодно.
Важно то, что в конце концов в любом случае точка зрения заказчика будет правильной.
Просто если вы его переубедите, то и вы останетесь правы.
Если он сотрудник клиента (маркетолог, тех специалист или еще кто) то самое логичное и правильное вести диалог с ним. Т.к. в вашем случае это ваш сотрудник, то действительно проблемно объяснить причину того или иного дизайнерского решения.
-и этому перечат не документы, а здравый смысл
Чей здравый смысл? Ваш, или вашего клиента? Вы уверены, что правильно оцениваете целевую аудиторию сайта? Может это жены друзей клиента которые просто обожают такой декор?
У вас есть только один вариант. Привести здравый смысл клиента и ваш к общему знаменателю. Вообще надо говорить на том языке на котором разговаривают с вами.
Зачастую при таких спорах тех специалисты исполнителя говорят на языке который не понятен заказчику. Потом оба расходятся в полной уверенности собственной правоты и дебилизма собеседника.
Убедите клиента, что «бабла такой сайт не будет зарабатывать ну ваааще» и «реально такое изменение уменьшит ваш доход»
Только надо все аргументировать, а не говорить что ваша Жена не фига не смыслит в сайтах.
Вопрос в том, кто формировал техзадание, точнее на чьей стороне?
Если оно противоречит вашему чувству прекрасного и принципам по которым отбираете сайты в портфолио, то это лично ваши проблемы.
Сайт, который не удовлетворят тому что описано в контракте/заказе/тз — плохой сайт.
И там четко прописано кто и за что отвечает.
В случае с сайтом такого нету.
Его надо убеждать или делать как он скажет.
Вообще понятие хорошего дизайна эксплуатируемое в статье, очень сильно завязано на ответы на вопросник, который приведен в конце. Без него непонятно как вообще можно говорить и конкретном дизайне.
До этого знал только про GIMP и Paint.NET
Что делать, когда команда уже наполнена мотивированными людьми. Когда они сами хотят брать на себя ответственность. Надо решать, кому и что давать.
Ведь в проекте всегда есть интересные места и не очень.
Как сохранить мотивацию тех, кто получил неинтересное направление и т.д.
Факт в том, что если убрать указанные мною ключи из конфига системы, то проблема исчезает.