Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 165
Может быть это лучше в веб-разработку перенести?
Очень правильно. Спасибо.
> правильный разобравшийся программист просто обрамляет заголовок тегом h1
как-то у вас не по-русски… почему программиста волнуют такие вопросы? по идее, это задача человека, ответственного за внедрение шаблона в проект, коим обычно является верстальщик.
более того, по моему опыту, верстальщик после того, как сам приделает свою верстку в проект, сам начинает задумываться о том, что все-таки стоит меньше копипастить, а больше работать головой и в следующий раз выдает более качественный код.
как-то у вас не по-русски… почему программиста волнуют такие вопросы? по идее, это задача человека, ответственного за внедрение шаблона в проект, коим обычно является верстальщик.
более того, по моему опыту, верстальщик после того, как сам приделает свою верстку в проект, сам начинает задумываться о том, что все-таки стоит меньше копипастить, а больше работать головой и в следующий раз выдает более качественный код.
Серега. Ну неужели у вас каждую строчку и каждую формочку внедряет верстальщик?
В целом внедрением шаблонов занимается верстальщик. Но... потом-то все начинают фигачить. :) ту или иную форму все равно программисты прикручивают в админке или непосредственно на сайте.
В целом внедрением шаблонов занимается верстальщик. Но... потом-то все начинают фигачить. :) ту или иную форму все равно программисты прикручивают в админке или непосредственно на сайте.
Нет конечно, порой сам "копипащу" одну из другой, но они и вписываются в страницу ровно так же, как вписывалась или нет исходная форма. Когда дело доходит до того, что надо что-то "подпилить напильником", к примеру, повесить класс на какой-то элемент, я ставлю соотв. задачу верстальщику — устно. Причем я не говорю, как именно нужно решить возникшую проблему, а просто ставлю его перед задачей, а после контролирую, объясняю ошибку (если есть) и еще раз ставлю задачу переделать правильно. В результате работы двух человек, один из которых знает, как сделать, а второй, как это должно быть сделано, получается лучше, чем кто-то делал бы это сам. И верстальщик обучается.
Согласен. Похоже, в конторе у автора и Smarty и MVC отменили...
А как Smarty и MVC относится к тому, что написано выше?
> правильный разобравшийся программист просто обрамляет заголовок тегом h1
как-то у вас не по-русски… почему программиста волнуют такие вопросы?
как-то у вас не по-русски… почему программиста волнуют такие вопросы?
Ну и все же как к этой цитате прикрутить смарти и мвц? Или упор делать на "программист" и "обрамляет"?
... другими словами: почему по мнению автора "программист обрамляет заголовок тегом h1"? Разве это не верстальщик должен делать?
Так а причем же все-таки здесь все-теже MVC и Smarty, если Вы пишите про разделение труда? MVC - шаблон проектирования (Model-View-Controller), Smarty - шаблонный движок.
при том, что MVC и Smarty избавляют программиста от процедуры "обрамления заголовка тегом h1"
Пост не про обрамление заголовков, а про качество. С ботинками должно быть понятнее.
Это каким образом Смарти его от этого избавит? Один хрен если придётся фигачить, ничего не спасёт :)
Ну, если фигачить, то конечно, не спасет, а если серьезно, то http://smarty.php.net/whyuse.php
Да, если придерживаться MVC, такой ситуации не возникнет. Минус влепил не очень умный человек.
Вы хотите сказать, что если использовать MVC, то проект с первого раза получается качественным и без багов?
Я тут не о технологиях пишу, а о людях. Скорее о частой организационной проблеме.
Я тут не о технологиях пишу, а о людях. Скорее о частой организационной проблеме.
> правильный разобравшийся программист просто обрамляет заголовок тегом h1
разобравшийся в MVC программист ничего не обрамляет тегом h1.
разобравшийся в MVC программист ничего не обрамляет тегом h1.
Это был своего рода образовательный пример поясняющий мысль.
Там есть вротой про доработки. Его тож MVC решает?
Там есть вротой про доработки. Его тож MVC решает?
MVC позволяет решить проблему отделения данных от способа отображения, остальное зависит от людей.
В последних моих сайтах, нет ни одного html тэга за пределами директории view. И мне до лампочки, что там делает верстальщик. И это у нас взаимно.
В последних моих сайтах, нет ни одного html тэга за пределами директории view. И мне до лампочки, что там делает верстальщик. И это у нас взаимно.
Программисту нельзя так полностью уходить от вопросов оформления. Например, текст новости с форматированием, которая храниться в базе данных. А статью нужно выводить как для основного сайта так и для wap версии, где уже совершенно другое оформление и другие тэги или например внутренние ссылки нужно исправлять специально под wap версию. Не думаю что будет правильно в данном случаи все скидывать на верстальщика. Хотя с позиции MVC в wap версии меняется только компонента View.
В статье как раз и говорится о том что отношение типа "И мне до лампочки, что там делает ..." может как раз и завести в тупик всю команду.
В статье как раз и говорится о том что отношение типа "И мне до лампочки, что там делает ..." может как раз и завести в тупик всю команду.
А разве данный пост только для PHP проектов?
У нас крупный интернет проект. Действует жёсткое.. железобетонное правило, программисты - не меняют ни строчки html кода, и верстальщики - ни строчки php & js. Это соблюдается. И тем не менее, вот ведь апофеоз квинтессенции разработки: описанные проблемы в точности существуют. Правда механизмы их возникновения немного другие..
гм… а подробнее про механизм можно? по мне так если в процессе "доделывания" программеры передали в шаблон какие-то дополнительные данные, а верстальщики их грамотно отобразили (т.е. каждый сделал ровным счетом свою часть работы), то таких косяков быть не должно.
программеры передали в шаблон какие-то дополнительные данные, а верстальщики их грамотно отобразили
а откуда верстальщик узнает как именно обозваны переменные? Или ему запускать Smarty debugger и домысливать что и куда. Не проще ли когда программер минимально набросает шаблон и уже это уходит верстальщику?
Косяки они ведь не только на стыке программист-верстальщик. Стыков в крупном проекте много: Менеджер(ы)-тех.писатель-программист(ы)-тестировщик(и)-верстальщик(и)-сеооптимизатор-и.т.д. Но даже если все казалось бы стыки смазаны и законопачены - косяки пролезают, например, из-за:
1. Не верной трактовки/формулировки задачи, особенно если задача является подзадачей, которых очень много в решении одной большой задачи (а в крупном проекте это именно так). И недопонимание-то может быть совсем крошечным, но суперпозиция таковых, в конечном итоге и даёт аховое отклонение.
2. Коррекции промежуточной задачи на этапе реализации. Жизнь всегда вносит коррекции, особенно если проект крупный и уже работающий, а не стартап. И тут как водится, в одном месте чхнёшь - в другом швы трещат.
Это на вскидку.. а на практике много разных обстоятельств приводит к тому, что продукт оказывается не таким качественным как было запланировано. И одно можно сказать точно, 90% этой беды - проблема организационная.
1. Не верной трактовки/формулировки задачи, особенно если задача является подзадачей, которых очень много в решении одной большой задачи (а в крупном проекте это именно так). И недопонимание-то может быть совсем крошечным, но суперпозиция таковых, в конечном итоге и даёт аховое отклонение.
2. Коррекции промежуточной задачи на этапе реализации. Жизнь всегда вносит коррекции, особенно если проект крупный и уже работающий, а не стартап. И тут как водится, в одном месте чхнёшь - в другом швы трещат.
Это на вскидку.. а на практике много разных обстоятельств приводит к тому, что продукт оказывается не таким качественным как было запланировано. И одно можно сказать точно, 90% этой беды - проблема организационная.
А в конце статьи можно написать примерно такое:
Но сколько Вы статей не читайте, придет дедлайн и Вы все равно будете фигачить :)
Но сколько Вы статей не читайте, придет дедлайн и Вы все равно будете фигачить :)
Качество страдает больше всего именно на этапе передачи html-шаблонов от верстальщика к программисту. Проверено. Меня всегда удивляло, каким образом хорошо сверстанные красивые проекты превращаются в полное говно, когда верстку натягивают на проект. Так что тут верстальщику и программисту необходимо утвердить для себя некие гайдлайны совместной работы. Или даже этим должен заняться проджект менеджер и убедиться, все ли под контролем.
Иногда, сверстанный макет не учитывает некоторых моментов, которые важны для программиста, а верстальщик говорит, что деньги за свою часть работы уже получил и ничего не будет делать бесплатно. И он тоже прав.
Вот такие дела.
Вот такие дела.
Совершенно верно. Именно поэтому верстальщику с программистом следует договариваться именно до начала верстки, а не после.
И сверстанные макеты должны быть одобрены программистом.
Чаще всего я получал макеты в которых просто некуда выводить сообщения об ошибках (если имеется форма).
Чаще всего я получал макеты в которых просто некуда выводить сообщения об ошибках (если имеется форма).
А место для сообщения об ошибках должен предусмотреть проектировщик интерфейсов.
Дык это все равно должно заранее обсуждаться.
:) похоже, я не одинок в своей проблеме
Я бы сказал, сверстанный макет никогда полностью не учитывает всех моментов…
Например для формы — сообщения об ошибках (для элементов и формы в целом).
Например для формы — сообщения об ошибках (для элементов и формы в целом).
Думаю что стандарт для верстки + хорошее общение программиста и верстальщика помогут избежать вышеописанных проблем.
Такие ситуации чаще возникают в конторах где у сотрудников слабая мотивация и нет желания делать качественно, как в примере с итальянским конвейером.
Такие ситуации чаще возникают в конторах где у сотрудников слабая мотивация и нет желания делать качественно, как в примере с итальянским конвейером.
Офигеть. А какое вообще отношение программист может иметь к верстке ???
а программер php когда допустим на cms цепляет, он, простите, с чем работает?
а с xml-данными.
Когда как.
В общем понятно, что необязательно xml, но суть от этого, имхо, не меняется. Программист выдает в какой-то форме данные, которые используются шаблоном (версткой). Если у программиста появляется задача думать на уровне "h1 с классом block" - это, согласитесь, просто отсутствует отделение данных от представления. Эрго, проблема не в распределении обязанностей и ответственности, а в отсутствии нормальных технологий.
Да уж. С технологиями у меня проблема :-)
Ибо, думать на уровне «h1 с классом block» приходится часто.
Ибо, думать на уровне «h1 с классом block» приходится часто.
Вообще там как раз написано, что он и не думает об этом. Просто рыбу обрамляет и все. Ошибки могло бы и не быть, а она есть. Я там классическую ошибку описал, которая и у верстальщиков встречается.
И вообще пост не про верстку, а про отношение к делу.
И вообще пост не про верстку, а про отношение к делу.
а почему именно php? в общем случае задача программиста заключается в том, чтобы сформировать набор данных и определить, по какому шаблону они должны быть отображены. само отображение (будь то xslt-преобразование или формирование html по шаблону в smarty) — задача верстальщика. того человека, который один занимается всем этим, следовало бы называть веб-разработчиком. по-моему, это более широкое понянтие.
В общем-то это был просто пример. Пост не об этом.
У нас в компании выработались следущие отношения между программерами и верстальщиками:
1. Четкая работа по паттернам в которых верхним элементом является View значительно упрощает жизнь. Во-первых, у всех верстальщиков есть доступ к шаблонам в репозитории, все баги с версткой идут к ним, а не к программерам, задача последних - правильно вписать нужное значение в placeholder. Программерский труд слишком дорог, чтобы они маялись с такой фигней.
2. Все шаблоны до внедрения их в систему тщательно тестируются, обсуждаются, брейнвошатся и прорабатывается принципы работы элементов на них, без утвержденного ТЗ программеры начинают ныть.
3. Используется ОБЯЗАТЕЛЬНЫЙ просмотр коммитов в репозиторий всеми членами команды (или одним ответственным человеком), после чего собираются "летучки" на которых обсуждается правильность каких-либо решений, причем очень часто программеры сами инициируют такие "летучки", обсуждают в своем кругу им только понятные проблемы и пишут на уайтборде слово "Х@Й".
4. Обязательно использутеся багтрекер, причем не просто формально - в нем идут реальные баталии иногда, к тому же это единственный способ доказать потом манагеру, что ты кого-то попросил, а он на тебя забил.
В принципе, в комманде каждая группа людей должна отвечать за свой слой и иметь доступ к нему, доступ же к чужим слоям должен быть только read-only, и манагер должен понимать с какой проблемой кого сношать.
1. Четкая работа по паттернам в которых верхним элементом является View значительно упрощает жизнь. Во-первых, у всех верстальщиков есть доступ к шаблонам в репозитории, все баги с версткой идут к ним, а не к программерам, задача последних - правильно вписать нужное значение в placeholder. Программерский труд слишком дорог, чтобы они маялись с такой фигней.
2. Все шаблоны до внедрения их в систему тщательно тестируются, обсуждаются, брейнвошатся и прорабатывается принципы работы элементов на них, без утвержденного ТЗ программеры начинают ныть.
3. Используется ОБЯЗАТЕЛЬНЫЙ просмотр коммитов в репозиторий всеми членами команды (или одним ответственным человеком), после чего собираются "летучки" на которых обсуждается правильность каких-либо решений, причем очень часто программеры сами инициируют такие "летучки", обсуждают в своем кругу им только понятные проблемы и пишут на уайтборде слово "Х@Й".
4. Обязательно использутеся багтрекер, причем не просто формально - в нем идут реальные баталии иногда, к тому же это единственный способ доказать потом манагеру, что ты кого-то попросил, а он на тебя забил.
В принципе, в комманде каждая группа людей должна отвечать за свой слой и иметь доступ к нему, доступ же к чужим слоям должен быть только read-only, и манагер должен понимать с какой проблемой кого сношать.
Ни в коем случае в этой ситуации нельзя винить дизайнера / верстальщика / программиста, виновато руководство неправильно организовавшее рабочий процесс.
ИМНСХО, единственный комментарий, не свалившийся в "как у нас в компании". (-;
Качество достигается именно четким следованием инструкциям с одной стороны, и их постоянным совершенствованием — с другой. Задача исполнителя — следовать инструкции, данной начальником, и сообщать ему об отклонениях и возможных улучшениях. Задача начальника же — поставить процесс так, чтобы в нем не возникало исключительных ситуаций.
Качество достигается именно четким следованием инструкциям с одной стороны, и их постоянным совершенствованием — с другой. Задача исполнителя — следовать инструкции, данной начальником, и сообщать ему об отклонениях и возможных улучшениях. Задача начальника же — поставить процесс так, чтобы в нем не возникало исключительных ситуаций.
Их никто не винит. Прочтите внимательно пример с обувью, а то с HTML много психологической инерции проявляется, мешающей понять мысль. Да в целом по итогу плохой обуви не выходит и во всем виновато руководство, а все остальные формально правы. Но ботинки получаются дорогие и не качественные.
Вывод не полный, нужна не только ответственность исполнителя (я сам отвечаю за свои решения), но и доверие руководителя (он сам принимает решения).
Из моего поста понятно, что доверие есть?
Вопрос или утверждение. Мне понятно что нет доверия. Да и обсуждение сводится к тому как разделить работу верстальщика, дизайнера и программиста. А сам пост на какую целевую аудиторию расчитан? Если не на руководителя то это выглядет как лозунг, призыв хорошо работать. Большинство исполнителей инертны в этом плане и не станут менять подход к своей, а тем более к работе смежников. Уверен что в примере с обувью, не работник конвейера сам начал снимать брак, ему доверили это делать (без последствий). В Вашем посте упор делается все таки на то что "По-настоящему талантливые разработчики должны перестать боятся брать на себя ответственность", те они сами должны что то взять. Нет это забота руководителя поделиться полномочиями.
Про ботинки это яркий пример менталитета. Это у нас не только в разработке проявляется, а вообще повсеместно в производстве.
Делимся полноночиями. За ошибки палкой по рукам не стучим.
Вы говорите сейчас из той же будки менталитета: начальство скажет можно, значит можно. И дальше ждут что же скажет начальство...
Должны сами брать. Не _заставлять_ же их брать отвественность! Так тем более никто не возьмет. В этом случае будет идти речь о спихивании отвественности.
Делимся полноночиями. За ошибки палкой по рукам не стучим.
Вы говорите сейчас из той же будки менталитета: начальство скажет можно, значит можно. И дальше ждут что же скажет начальство...
Должны сами брать. Не _заставлять_ же их брать отвественность! Так тем более никто не возьмет. В этом случае будет идти речь о спихивании отвественности.
Менталитет говорите, откуда такая вера в то что иностранцы награждены какимто особым отношением к делу? Почему считаете что итольянец будет корчится в душевных муках из за пропущеного брака? Откуда такая уверенность в ущербности собственного народа? Менталитет. Вы не задумывались что там просто наказывают за то что пропустил брак дальше? Ответственные работники заслуга руководства и одна из основных его задач. Еще одна задача руководства поиск работников готовых брать на себя такую ответственность. А Ваши слова о том что пусть сами возьмут, и есть перекладывание ответственности но уже не за их участок работ, а за свой собственный. Руководитель организует работу и работников а не наоборот. Но это все конечно из будки моего российского менталитета.
1. Менталитет у нас и у, скажем, европейцев действительно разный. Отрицать это бесполезно, можно для начала просто попробовать поездить по Европе и поговорить с людьми, если соотвествующих книжек не хватает.
2. Не нравится пример с браком? Могу привести пример просто житейский, когда сосед вызывает полицию и сообщает о неправильной парковке свого соседа, полиция приезжает и оштрафовывает его. Для них это соблюдение законности, для нас... стукачество. Я не говорю, что это везде в Европе так, но в Финляндии, Германии, Чехии и пр. так есть.
3. Про менталитет я бы слов попусту не бросал. Вот у нас всегда так: во всем начальство виновато. В подъезде грязно — кровавый режим у власти. Как говорил профессор Преображенский: "Разруха не клозетах, а в головах". ;)
2. Не нравится пример с браком? Могу привести пример просто житейский, когда сосед вызывает полицию и сообщает о неправильной парковке свого соседа, полиция приезжает и оштрафовывает его. Для них это соблюдение законности, для нас... стукачество. Я не говорю, что это везде в Европе так, но в Финляндии, Германии, Чехии и пр. так есть.
3. Про менталитет я бы слов попусту не бросал. Вот у нас всегда так: во всем начальство виновато. В подъезде грязно — кровавый режим у власти. Как говорил профессор Преображенский: "Разруха не клозетах, а в головах". ;)
И еще: покажите мне место, где я говорил про "ущербности собственного народа"?
Просто я этот народ пытаюсь чуть лучше узнать. И данный пример менталитета не хороший и не плохой, он просто есть и мы с ним живем. Но местами он нам мешает.
Вообще этот разговор слишком большой и для этой статьи и вообще мало подходит этому сайту.
Просто я этот народ пытаюсь чуть лучше узнать. И данный пример менталитета не хороший и не плохой, он просто есть и мы с ним живем. Но местами он нам мешает.
Вообще этот разговор слишком большой и для этой статьи и вообще мало подходит этому сайту.
Ваши слова о том что "Это у нас не только в разработке проявляется" наводят именно на такую мысль. Почему "этот"? Хотя ладно, не суть. А вообще менталитет здесь не причем. Ведь если следовать логике менталитета, то немцы (все просто по тому что немцы) пунктуальные а японцы исключительно ответственные. Но тогда у меня вопрос, зачем же именно в японии начали на производстве создавать кружки качества? Наверное оно было не на требуемом уровне. Считаю что вопросы качества в достаточной мере изучены и просто нужно применять готовый опыт. В том числе и кружки качества организовывать. На мой взгляд статья Ваша слишком общая, если бы была большая фокусировка на практических решениях, с конкретными примерами достижения качества в сфере веб разработок, ценность её была бы значительно больше.
Человек, который хочет чего-то достичь в профессиональном плане, должен сам стремиться брать на себя более серьезные задачи, а значит более серьезную ответственность. От хорошего специалиста ждут инициативы, а не следования инструкции. Если руководитель с гриппом слег — все остановится? А если он в командировке? А если просто отъехал на встречу? Много денег не получают, а зарабатывают.
Отличный специалист видит для себя возможность взять полномочия и предлагает руководителю. Хороший показывает себя с лучшей стороны и руководитель в каких-то случаях может дать ему полномочия. Середнячки сидят тихо и никуда не рвутся. В посте речь о том, что хочется работать с первыми.
Отличный специалист видит для себя возможность взять полномочия и предлагает руководителю. Хороший показывает себя с лучшей стороны и руководитель в каких-то случаях может дать ему полномочия. Середнячки сидят тихо и никуда не рвутся. В посте речь о том, что хочется работать с первыми.
А так пост о желаниях. Я то думал о том как выстроить работу организации, как сделать так, чтобы люди хотели брать на себя ответственность.
Пост как раз о том как выстроить работу организации. Наличие отличных специалистов помогает сделать это гораздо проще. Если не брать за организацию 3 человек, делающих промо-сайты, а развивающуюся команду, которой вместе работать интересно и предстоит еще долго — вопросы развития команды влияют на процесс очень и очень.
Внутренний процесс — это ведь не только выполнение конкретных задач. Команда ведь собралась не для того, чтобы сделать, скажем, е-магазин и разбежаться.
Внутренний процесс — это ведь не только выполнение конкретных задач. Команда ведь собралась не для того, чтобы сделать, скажем, е-магазин и разбежаться.
Вы представляете что такое процесс производства? Обратитесь к промышленным стандартам, RUP или другим. Никто в здравом уме не будет говорить что для успеха не нужны отличные специалисты. Но говорить (с учетом долгосрочной перспективы) Бумажки-инструкции, четкое "Бумажки-инструкции, четкое следование административной иерархии — это признаки слабости ума" это как то странно. Опять таки, отказ от документационного обеспечения процессов для организации из 3 человек это справедливо и даже желательно.
Процесс я себе отлично представляю, в нем участвую и отчасти — выстраиваю. Фраза про слабость ума при следовании инструкциям, наверное, чересчур категорична. Но суть поста в том, что формальные инструкции не могут предусмотреть всего многообразия жизненных и проектных ситуаций и без включения головы и ответственности исполнителя получится как в истории с ботинком. Формально все сделано правильно, а по факту — зря потрачено время и материалы. Можно сказать, что такую ситуацию тоже нужно прописать и все будет в порядке. Но необъятного объять нельзя и написать ТЗ на вселенную — тоже, поэтому рано или поздно всплывает другая ситуация. И тут гораздо лучше иметь умного и ответственного сотрудника. В больших масштабах степень этой ответственности не может быть большой — иначе процесс развалится. Но все-таки быть должна и чем более компактная команда — тем больше персональной ответственности.
По промышленным стандартам может жить большая сложная организация. Организация в 10-15 человек держится на конкретных людях. Следование промышленным стандартам скорее повредит подобной компании.
Да, согласен с таким моментом :)
Но есть и еще один проблемный участок...
Палка на двух концах так сказать :)
Чтобы ускорить процесс разработки нужно разделить роли и сделать так чтобы каждый член команды сконцентрировался на собственной задаче. А это приводит к тому, что человек имеет великолепное представление об какой-то одной области, но оставшиеся куски проекта для него - темный лес.
И вторая сторона -
Чтобы увеличить, скажем, чуткость, внимательность к проекту, необходимо понимание проекта как единого целого! Ведь без этого человек не сможет и чужие баги замечать, и замечать некрасивые участки и предлагать идеи по усовершенствованию. То есть блюсти качество проекта.
И прекрасно понятно, что на стартовом этапе, когда даже у дизайнера и проектировщика интерфейса в голове гремучая смесь из: «да, это круто, это надо», «о здесь, надо так», «о, вот этот финт мы используем», говорить о понимании проекта как единого целого просто и говорить не стоит… И только через несколько итераций (см. про это написано в статье) формируется понимание направления движения проекта
Но есть и еще один проблемный участок...
Палка на двух концах так сказать :)
Чтобы ускорить процесс разработки нужно разделить роли и сделать так чтобы каждый член команды сконцентрировался на собственной задаче. А это приводит к тому, что человек имеет великолепное представление об какой-то одной области, но оставшиеся куски проекта для него - темный лес.
И вторая сторона -
Чтобы увеличить, скажем, чуткость, внимательность к проекту, необходимо понимание проекта как единого целого! Ведь без этого человек не сможет и чужие баги замечать, и замечать некрасивые участки и предлагать идеи по усовершенствованию. То есть блюсти качество проекта.
И прекрасно понятно, что на стартовом этапе, когда даже у дизайнера и проектировщика интерфейса в голове гремучая смесь из: «да, это круто, это надо», «о здесь, надо так», «о, вот этот финт мы используем», говорить о понимании проекта как единого целого просто и говорить не стоит… И только через несколько итераций (см. про это написано в статье) формируется понимание направления движения проекта
(Что-то не дошел кусочек финальный)
Вот и встает таск к руководству – как бы так балансировать между двух концов палки? И чтобы все в итоге были довольны?
Вот и встает таск к руководству – как бы так балансировать между двух концов палки? И чтобы все в итоге были довольны?
Вообще, в крупных компаниях принцип "разделяй и властвуй" очень широко применим. По сути, все принципы ООП пропагандируют это: Вы пишете интерфейс, реализуете его, пишете документацию к интерфейсу. Все. Исходя из этого складывается ситуация: если кому-то что-то надо поменять в вашем куске кода, он пишет вам запрос и вы это делаете. Это гораздо проще и выгоднее т.к. никто не знает ваш фрагмент кода лучше, чем вы сами а изучение его посторонним человеком потребует времени. Зато с другой стороны, люди занимающиеся разработкой других частей приложения связанных с вашим классом всегда точно знают к какому методу интерфейса обратиться или расширяют базовый класс под свои нужды.
Построение таких приложений без системного архитектора задача сложная, но не невозможная. Надо только не забывать, что программист по сути негр и раб, и если ему давать слишком много свободы, то ни к чему хорошему это не приведет, скорее всего от осознания своей всесильности код станет запутанным и неподдающимся отладке, причем программист не будет в этом виноват - архитектура приложений не его работа и задача, паттерны должны знать люди, занимающиеся дизайном приложений и следящие за тем, чтобы их указания беспрекословно выполнялись. Только в этом случае возможно написание надежного модульного кода.
и пару слов о повышении ответственности, я считаю, что программист должен иметь право проинформировать ПМ о тех вещах, которые ему кажутся спорными, может спорить до посинения, но без согласования и одобрения ему должно быть категорически запрещено вносить самовольно изменения не укладывающиеся в рамки дизайна, такие случаи уже были и по шапке получали все, я все-таки считаю, что ответственность за проект несет Project Manager и в его интересах держать ситуацию под контролем.
Построение таких приложений без системного архитектора задача сложная, но не невозможная. Надо только не забывать, что программист по сути негр и раб, и если ему давать слишком много свободы, то ни к чему хорошему это не приведет, скорее всего от осознания своей всесильности код станет запутанным и неподдающимся отладке, причем программист не будет в этом виноват - архитектура приложений не его работа и задача, паттерны должны знать люди, занимающиеся дизайном приложений и следящие за тем, чтобы их указания беспрекословно выполнялись. Только в этом случае возможно написание надежного модульного кода.
и пару слов о повышении ответственности, я считаю, что программист должен иметь право проинформировать ПМ о тех вещах, которые ему кажутся спорными, может спорить до посинения, но без согласования и одобрения ему должно быть категорически запрещено вносить самовольно изменения не укладывающиеся в рамки дизайна, такие случаи уже были и по шапке получали все, я все-таки считаю, что ответственность за проект несет Project Manager и в его интересах держать ситуацию под контролем.
понравилось слово "фигачить" - очень правильно, жизненно и все знакомо :)
Это просто один день из нашей фирмы!
"Качество снижается на этапах передачи работы от одного сотрудника другому." Наиболее простой (но не самый дешевый) способ минимизировать снижение качества - посадить всех в одну комнату (с невысокими перегородками). Чтобы команда варилась в едином бульоне. Чтобы для решения как серьезного, так и мелкого вопроса, программисту достаточно было поднять голову и громко крикнуть: "Вась, какой тут нахрен тег ставить?". Работает безотказно. Но если дизайнер - в Киеве, а программист - в Новосибе, тут уже нужно мастерство организатора. Кстати, как показывает практика, издержки снижения качества от удаленного общения далеко не всегда компенсируют выгоду от наёма фрилансера. Я, например, в аутсорс отдаю только небольшие и независимые от общего проекта дела.
Работает, но я против криков с рабочего места, потому что это мешает коллегам. Людям надо больше сосредоточиваться на своей задаче, погружаться в поток.
Нифига подобного. Ничему это не мешает, а наоборот помогает быть в курсе того что происходит вокруг. Заметил: если программист зашорин и чего-то там фигачит, жди от него подвоха.
Одно другого не исключает.
Короткие митинги лучше, чем постоянное повышение голоса.
Короткие митинги лучше, чем постоянное повышение голоса.
Довольно весело читать мнение об "отвлекает или нет это программиста" от человека программистом не являющимся! :)
Товарищь, поверте, пожалуйста, наслово! Иногда за эти "Слушай, а как здесь", "Ой, а глянь а что тут" хочется просто врезать, не говоря уже о банальном послать.
Вы как-нибудь попробуйте хранить ветвистую картину, ну скажем логики рассылки уведомлений пользователю на сайте как хабр, объектное представление реализации этой логики в коде, который перед вашими глазами, нюансы связей между кодом, перечень ожидаемых от пользователя действий с этим модулем, нюансы связанные со скоростью работы модуля.
И просто поотвечайте на какие-нибудь банальные вопросы, типа "сколько времени?", "Ты читал вот эту статью?" Посмотрим что у вас получится как в ответах так и в коде :)
Товарищь, поверте, пожалуйста, наслово! Иногда за эти "Слушай, а как здесь", "Ой, а глянь а что тут" хочется просто врезать, не говоря уже о банальном послать.
Вы как-нибудь попробуйте хранить ветвистую картину, ну скажем логики рассылки уведомлений пользователю на сайте как хабр, объектное представление реализации этой логики в коде, который перед вашими глазами, нюансы связей между кодом, перечень ожидаемых от пользователя действий с этим модулем, нюансы связанные со скоростью работы модуля.
И просто поотвечайте на какие-нибудь банальные вопросы, типа "сколько времени?", "Ты читал вот эту статью?" Посмотрим что у вас получится как в ответах так и в коде :)
Только при решении подобных "мелких" вопросов очень часто возникает ситуация: Вася сказал Пете, какой тег надо вставить. В это время Ваня был на обеде. Вернувшись с обеда Ваня продолжает вставлять теги, причем не те, которые посоветовал Вася Пете, а те, которые ему так же устно посоветовал Коля. А потом ближе к концу рабочего дня раздается вопль на всю эту комнату с невысокими перегородками "Что за херь творится у нас на сайте?" (случается минимум раз в неделю)
C ума сойти! Просто удар в удар описанна ситуация у нас в команде! В итоге каждый сотрудник "приводит в порядок" то, что потом с трудом можно в портфолио добавить!))) и приходится заново все переделывать... Следовательно возникает еще одна проблема:
делаем
+корректируем
+переделываем
+ корректируем то что переделали
--------------------------------
Проект готов, но потрачено катастрофически много времени!
Может кто подскажет способ оптимизации? Может какимито проект менеджерами пользоваться...
делаем
+корректируем
+переделываем
+ корректируем то что переделали
--------------------------------
Проект готов, но потрачено катастрофически много времени!
Может кто подскажет способ оптимизации? Может какимито проект менеджерами пользоваться...
По-моему, беда в том, что качество результата далеко не всегда является установкой, действующей в масштабах всей компании, что не в последнюю очередь вытекает из целей и/или способностей (умственных, управленческих, лидерских — нужно подчеркнуть) руководства.
Иногда (нередко?) установкой (намеренно или фактически) в деятельности компании является не более чем при минимальных усилиях тянуть деньги с клиентов, которые [до поры до времени] не понимают, что за свои же деньги получают некачественный, негибкий и, по сути, заведомо мёртвый продукт. Руководство же не всегда способно понять, что такая стратегия обязательно приводит к топтанию на месте (когда в действительности нет перспектив развития компании, даже если этого не осознаёт сам руководитель, блаженно веруя, что когда-нибудь фирма достигнет высот), а в конечном счёте — и к упадку, в дальнейшем.
Иногда (нередко?) установкой (намеренно или фактически) в деятельности компании является не более чем при минимальных усилиях тянуть деньги с клиентов, которые [до поры до времени] не понимают, что за свои же деньги получают некачественный, негибкий и, по сути, заведомо мёртвый продукт. Руководство же не всегда способно понять, что такая стратегия обязательно приводит к топтанию на месте (когда в действительности нет перспектив развития компании, даже если этого не осознаёт сам руководитель, блаженно веруя, что когда-нибудь фирма достигнет высот), а в конечном счёте — и к упадку, в дальнейшем.
Вот я руководство. Ставлю качество во главу угла. Описываю проблемы, которые всеравно появляются.
Думаете надо просто решить делать качественно и все будет?
Думаете надо просто решить делать качественно и все будет?
Желание предшествует действию. Чтобы сдвинуть предмет, недостаточно подумать об этом. Чтобы обеспечить качественный результат, недостаточно только захотеть этого. Собственно, я разделяю многие из озвученных вами моментов, однако полагаю, что установка на качество действительно эффективна, только если приходит сверху, а не снизу, и не в виде абстрактной идеи («с сегодняшнего дня делаем качественно»), а в форме конкретных, продуманных и скоординированных мероприятий по совершенствованию рабочего процесса. Например, один толковый сотрудник ничего не сможет сделать, если — возьмём крайний случай — весь курс развития компании тупиковый, а руководитель этого не понимает или понимать не хочет.
Я думаю что причиной скоре всего не слаженность команды. Когда команда думает в одном направлении и все участники четко знают что можно "ждать" от соседа будет работать четко и без сбоев. К сожалению на создание таких команд неверное не существует, но к этому нужно всем стремиться.
Даже если команда сработалась, всеравно будут появляться такие моменты, типа: "Руководство подумало и решило отдать дизайн||верстку||програмирование||ваш_вариант". И после этого все начинают веселиться...
Я даже не поверю что кто-то работает в идеальной команде. Но верю что команд в которой я работую завтра будет лучше, после завтра еще лучше и так до бесконечности. А самое главное прилагаю все силы для этого.
Даже если команда сработалась, всеравно будут появляться такие моменты, типа: "Руководство подумало и решило отдать дизайн||верстку||програмирование||ваш_вариант". И после этого все начинают веселиться...
Я даже не поверю что кто-то работает в идеальной команде. Но верю что команд в которой я работую завтра будет лучше, после завтра еще лучше и так до бесконечности. А самое главное прилагаю все силы для этого.
по-моему разработчикам нужно, наоборот, перестать бояться отказываться от ответственности. а то будет все именно так как вы написали. иначе потом концов не найдешь.
проблемы взаимодействия являются самыми сложными. и говорить о том что все решается увеличением ответственности, суть влезанием в чужую область работ может помочь только если "влезальщик" готов работать по двенадцать часов. и то на время. "влезальщик", он же "талант" и человек, не боящийся брать на себя ответственность, конечно сделает так чтобы все работало. для него это будет понятно и красиво. а для тех людей, которые будут заниматься последующией поддержкой, доработкой и пр. пр.? вот здесь качество начинается.
проблемы взаимодействия являются самыми сложными. и говорить о том что все решается увеличением ответственности, суть влезанием в чужую область работ может помочь только если "влезальщик" готов работать по двенадцать часов. и то на время. "влезальщик", он же "талант" и человек, не боящийся брать на себя ответственность, конечно сделает так чтобы все работало. для него это будет понятно и красиво. а для тех людей, которые будут заниматься последующией поддержкой, доработкой и пр. пр.? вот здесь качество начинается.
Статья однозначно хорошая, но есть одно маленькое замечание: стоило бы в первом абзаце указать, что речь идёт о веб-разработке, я это понял не сразу. Понятно, что те же рассуждения применимы и в других областях ПО, но примеры ссылаются именно на этот случай.
Мы используем частично позаимствованные методики из ХР-программирования - владение кодом вдвоем. То есть:
1. Дизайнер режет макет вместе с верстальщиком. За эти 3-4 часа они успевают друг с другом обсудить детали, особенности.
2. Верстальщик первый день работает с программером вместе - навешивает шаблоны на типовые модули (типа, новостей, текста, поиска и пр.)
На первый взгляд - люди тратят некоторое время впустую... Но, как показывает практика, совместное сидение за монитором 2-х людей помогает не отвлекаться, лучше выискиваются ошибки, и есть преемственность действий. Но обо всем этом можно узнать из методики Экстремального Программирования, например, http://www.exprogramming.ru/
1. Дизайнер режет макет вместе с верстальщиком. За эти 3-4 часа они успевают друг с другом обсудить детали, особенности.
2. Верстальщик первый день работает с программером вместе - навешивает шаблоны на типовые модули (типа, новостей, текста, поиска и пр.)
На первый взгляд - люди тратят некоторое время впустую... Но, как показывает практика, совместное сидение за монитором 2-х людей помогает не отвлекаться, лучше выискиваются ошибки, и есть преемственность действий. Но обо всем этом можно узнать из методики Экстремального Программирования, например, http://www.exprogramming.ru/
Знаете как устроены фабрики по производству обуви в той же Италии?
Идет конвейер, на нем двигаются ботинки. У каждого отдельного работника есть свой четкий участок работы. Если к нему пришел ботинок с плохо проклеенной подошвой, то он не станет приклеивать на него носок, а отложит ботинок, а потом пойдет к начальнику цеха и сообщит о браке. Что сделает “наш” работник? Приклеит носок, потому что качество… не его работа. Для этого у нас есть ОТК. ОТК проверяет в конце конвейера ботинок и выкидывает его как брак. Да от брака мы избавились, но потратили время всего конвейера. Бракованный ботинок получился очень дорогим.
а почему вы решили, что в Италии работник конвейера сам принял решение о сообщении брака начальству? может быть это предусмотрено рабочей инструкцией? :)
Вот что я хочу сказать:
Бумажки-инструкции, четкое следование административной иерархии — это признаки слабости ума и таланта.
не нужно быть столь категоричным :)
недавно в секрете фирмы вышла статья Инструкция для самурая
и там есть интересное решение, которое придумали умные японцы для России :)
В ноябре 2007 года заработает завод Toyota под Санкт-Петербургом. Его сотрудники обучены так, что тяга к самосовершенствованию и полная самоотдача для них необязательны. В Toyota считают: в России можно стремиться к абсолютному качеству и сокращать издержки с той же эффективностью, что и в Японии. Для этого нужно лишь в точности следовать инструкциям. Фокус в менеджменте теперь приходится на стандартизацию процедур и дисциплину, а не на беспрерывное совершенствование.
что касается взаимодействия дизайнер-верстальщик-программист (все работают в офисе), то тут я вижу минимум два варианта.
1. компания маленькая и все сидят в одной комнате. идет постоянный диалог, существует возможность договориться, обсудить и найти решение, которое устроит всех. здесь все просто. :)
2. компания средняя или большая. все отделены друг от друга непреодолимыми барьерами :)
вот здесь, как мне кажется, и можно вводить минимальный набор инструкций. ни для того, чтобы говорить, я свою работу сделал, дальше делайте как хотите, а для того, чтобы, имея возможность решить одну задачу несколькими способами, из них выбрали наиболее эффективный для всего процесса.
или еще есть такой вопрос как текучесть кадров в большой компании и, чтобы обучение новых сотрудников было эффективным и быстрым, тоже неплохо бы иметь документированные базовые принципы работы :)
ну и плюс ко всему как и в случае маленькой компании - диалог, обучение друг друга, хотя это уже намного сложнее. в общем создания команды и командного духа, а не тупо конвейера :)
Вы знаете на что похоже четкое следование инструкциям? На еду в Макдоналдсе. Да это можно есть, но Макдональдс умеет делать только то, что разработано Институте питания Макдональдс. Больше ничего.
Если вам надо делать гамбургеры следуйте четким инструкциям.
Лично я хочу, чтобы наша команда делала не гамбургеры, а какое-нибудь "жаренное филе морского окуня, фаршированного овощами, запеченого на шапиньонах с соусом сальса-верде"(с).
Если вам надо делать гамбургеры следуйте четким инструкциям.
Лично я хочу, чтобы наша команда делала не гамбургеры, а какое-нибудь "жаренное филе морского окуня, фаршированного овощами, запеченого на шапиньонах с соусом сальса-верде"(с).
Юрий, что касается инструкций для IT, то я специально выделил слово минимальный, потому что оно здесь ключевое :)
не знаю чем вам насолил или недосолил макдональдс, но за свою цену они делают нормальную еду :)
вот если бы гамбургер стоил как филе морского окуня, то тогда были бы вопросы :)
не знаю чем вам насолил или недосолил макдональдс, но за свою цену они делают нормальную еду :)
вот если бы гамбургер стоил как филе морского окуня, то тогда были бы вопросы :)
Да инструкуции нужны и их должно быть минимальное количество. С этим не спорю. Говорю лишь о том, что иногда качество важнее "инструкций".
Мадональдс это есть унифицированное производство. Просто если в Ванкувере жарят котлету 37 секунд, то и в Минске ее тоже жарят 37 секунд. Уровень качества очень средний, но везде одинаковый.
Мы выпеканием "гамбургеров" не занимаемся, поэтому и наши услуги стоят не дешево.
Мадональдс это есть унифицированное производство. Просто если в Ванкувере жарят котлету 37 секунд, то и в Минске ее тоже жарят 37 секунд. Уровень качества очень средний, но везде одинаковый.
Мы выпеканием "гамбургеров" не занимаемся, поэтому и наши услуги стоят не дешево.
Кстати.
Когда начинают стимулировать плохой ботинок нести к начальнику, то тот от кого поступают такие ботинки получает по шапке. С т.з. начальства все верно, но в нашем менталитете заложено правило "мы и они". Идет сговор "не носить" ботинки начальству, а просто игнорировать их. Тогда "баги" уходят в тень, качество же остается на прежнем уровне или даже снижается.
Статью прочитаю.
Когда начинают стимулировать плохой ботинок нести к начальнику, то тот от кого поступают такие ботинки получает по шапке. С т.з. начальства все верно, но в нашем менталитете заложено правило "мы и они". Идет сговор "не носить" ботинки начальству, а просто игнорировать их. Тогда "баги" уходят в тень, качество же остается на прежнем уровне или даже снижается.
Статью прочитаю.
Все зависит от руководства - это правда, очень часто причины сбоев в простой халатности, которая лечится только мотивацей "ответственности за портфолио" и снижением нагрузки конвейра на него. Еще причина в постоянной текучести кадров, в Минске это проблема абсолютно всех студий, где обычно работают студенты год, два максимум. Ротом они уезжаю в РФ, уходят во фриланс или нормальное программирование (EPAM etc.) Качество снижается на этапах передачи работы от одного сотрудника другому - это факт. Решается уменьшением этапов, что практически невозможно осуществить в студиях. Но фрилансерам-дизайнерам в этом плане проще - огромная мотивация изучить весь процесс производства и стать в полном смысле веб-разработчиком.
Качество НЕ снижается если принимающая сторона присматривала за ходом этапа.
В чем, имхо, основная беда многих проджект-менеджеров - откуда-то взялась мысль что вот мы возмем, отдадим дизайн верстаку и через две недели мы получим готовую качественную верстку. А пока можно заняться чем-то еще. А не получается. Вернее получается как выше описано.
Я для решения этой задачи сделал приемку работы многоэтапной. Раз в два-три дня пробежаться по коду (или в данном случае попросить программера просмотреть верстку) не сложно и времени много не займет, зато львиную долю косяков и будущих костылей можно исправить в зародыше. В итоге через две недели программер получает верстку уже с его собственными коррективами, руководитель проекта первым узнает о проблемных участках, верстальщик постепенно срабатывается с программером и начинает понимать что программеру удобно, а что нет. В случае нового человека в команде опять же быстрее происходит интеграция в общую струю. Собственно все то же общение членов комманды, но инициированное сверху.
В чем, имхо, основная беда многих проджект-менеджеров - откуда-то взялась мысль что вот мы возмем, отдадим дизайн верстаку и через две недели мы получим готовую качественную верстку. А пока можно заняться чем-то еще. А не получается. Вернее получается как выше описано.
Я для решения этой задачи сделал приемку работы многоэтапной. Раз в два-три дня пробежаться по коду (или в данном случае попросить программера просмотреть верстку) не сложно и времени много не займет, зато львиную долю косяков и будущих костылей можно исправить в зародыше. В итоге через две недели программер получает верстку уже с его собственными коррективами, руководитель проекта первым узнает о проблемных участках, верстальщик постепенно срабатывается с программером и начинает понимать что программеру удобно, а что нет. В случае нового человека в команде опять же быстрее происходит интеграция в общую струю. Собственно все то же общение членов комманды, но инициированное сверху.
Большое спасибо за статью.
Очень классно.
Очень классно.
С удовольствием прочел.
Сам руковожу командой постановщиков и программистов. Пишем и внедряем на платформе 1С. Одно из решений, которое я попробовал - это общая зависимость от конечного результата. Т.е. премию получает команда за командный результат. А не так что, постановщик вовремя подписал и сдал ТЗ, которое вовремя оплатили и получил премию, а кодировщики замучились писать по этому ТЗ. В сущности это простое утверждение командного результата на уровне денежной компенсации. Вся команда сидит в одной лодке и если каждый будет грести как ему вздумается, мы никогда не приплывем туда, куда хотим приплыть. К сожалению в веб разработках не участвуем, но вот у нас постановщики очень часто консультируются с кодировщиками на предмет как лучше организовать тот или иной документ. Просто взгляд с разных точек зрения на один предмет. С моей точки зрения это подчас выглядит как постоянная болтовня. :-) Но результат есть. Просто надо видимо свести это к нормальным формальным митингам. Но это уже к данной теме не относится.
Сам руковожу командой постановщиков и программистов. Пишем и внедряем на платформе 1С. Одно из решений, которое я попробовал - это общая зависимость от конечного результата. Т.е. премию получает команда за командный результат. А не так что, постановщик вовремя подписал и сдал ТЗ, которое вовремя оплатили и получил премию, а кодировщики замучились писать по этому ТЗ. В сущности это простое утверждение командного результата на уровне денежной компенсации. Вся команда сидит в одной лодке и если каждый будет грести как ему вздумается, мы никогда не приплывем туда, куда хотим приплыть. К сожалению в веб разработках не участвуем, но вот у нас постановщики очень часто консультируются с кодировщиками на предмет как лучше организовать тот или иной документ. Просто взгляд с разных точек зрения на один предмет. С моей точки зрения это подчас выглядит как постоянная болтовня. :-) Но результат есть. Просто надо видимо свести это к нормальным формальным митингам. Но это уже к данной теме не относится.
Эта статья полезна для тех кто руководит проектами...
Если проектом управляет грамотный менеджер, который не приходит за 10 мин. до окончания рабочего дня и не даёт тебе задание на 3 часа, а сам уходит отдыхать, который видит добросовестных работников и поощряет их время от времени, который умеет планировать деятельность свою и своих работников, тогда "да"... я согласен "сообщать о браке", согласен активно участвовать в жизни проекта.
В другом случае "нет". Когда какая-нибудь бездарность приходит и говорит, например, "блин, надо через 10 мин. в печать макет плаката надо отдать, успеем быстренько переверстать и вот сюда десять логотипов добавить?", тогда о какой инициативе может идти речь? Да пошёл он лесом такой менеджер... ну плохой проект получится, ну и гори оно огнём...
Если проектом управляет грамотный менеджер, который не приходит за 10 мин. до окончания рабочего дня и не даёт тебе задание на 3 часа, а сам уходит отдыхать, который видит добросовестных работников и поощряет их время от времени, который умеет планировать деятельность свою и своих работников, тогда "да"... я согласен "сообщать о браке", согласен активно участвовать в жизни проекта.
В другом случае "нет". Когда какая-нибудь бездарность приходит и говорит, например, "блин, надо через 10 мин. в печать макет плаката надо отдать, успеем быстренько переверстать и вот сюда десять логотипов добавить?", тогда о какой инициативе может идти речь? Да пошёл он лесом такой менеджер... ну плохой проект получится, ну и гори оно огнём...
Это замечательный материал. Читая его, я постоянно пытался сопоставить подход с методологией управления XP, но сама статья описывала не сам процесс управления проектом, а околопроектные задачи, вкупе со мнением автора. Некоторые моменты, конечно же, спорные, но все же статья полезная. Автору +1.
Взял себе на заметку.
Взял себе на заметку.
Статья может быть и интересная, но не отображает настоящей действительности.
Интересный получается вывод, оказывается беда всех проектов - некомпетентные исполнители (верстальщики, программисты и пр) - т.е. работники, которые практически не принимают участие в проектировании.
Нет, чтобы им во время сказать нет, дальше делать не буду проект пока тот-то не исправит это...
Чушь полная.
Как проект спроектирован - так он и получится.
Если в самом начале у менеджера/заказчика нет четкого виденья того, что нужно будет получить в конечном результате и все ньюансы дорисовываются по "ходу пьесы" - никакого вразумительного качества не будет. Потому что на каждом новом этапе переделок, часть кода будет каментиться, а весь новый функционал будет приспосабливаться к тому что уже сделанно, так как с нуля никто не будет писать, когда сдача проекта уже на носу.
Очень часто с этим сталкиваюсь. Макет утвержден, сверстан и посажен на динамику. И тут начинается, а вот давайте тут зелененько, а тут красненько, а тут новый блок, то да се... И поехало такое безобразие.
Рыба гниет с головы, а веб-проект - с менеджеров и управленцев.
Как задача поставленна - так она и реализуется.
Интересный получается вывод, оказывается беда всех проектов - некомпетентные исполнители (верстальщики, программисты и пр) - т.е. работники, которые практически не принимают участие в проектировании.
Нет, чтобы им во время сказать нет, дальше делать не буду проект пока тот-то не исправит это...
Чушь полная.
Как проект спроектирован - так он и получится.
Если в самом начале у менеджера/заказчика нет четкого виденья того, что нужно будет получить в конечном результате и все ньюансы дорисовываются по "ходу пьесы" - никакого вразумительного качества не будет. Потому что на каждом новом этапе переделок, часть кода будет каментиться, а весь новый функционал будет приспосабливаться к тому что уже сделанно, так как с нуля никто не будет писать, когда сдача проекта уже на носу.
Очень часто с этим сталкиваюсь. Макет утвержден, сверстан и посажен на динамику. И тут начинается, а вот давайте тут зелененько, а тут красненько, а тут новый блок, то да се... И поехало такое безобразие.
Рыба гниет с головы, а веб-проект - с менеджеров и управленцев.
Как задача поставленна - так она и реализуется.
У нас как раз ничего не гниет. Просто пост стоит рассматривать с позиции внедрения гибких методик типа agile.
Работников, если вы не заметили, никто в этом не винит. Просто они бояться что взяв отвественность "получат по шапке". А на самом деле ошибки допустимы, верить только в это получается у разработчиков не сразу.
Работников, если вы не заметили, никто в этом не винит. Просто они бояться что взяв отвественность "получат по шапке". А на самом деле ошибки допустимы, верить только в это получается у разработчиков не сразу.
1) О каких гибких методиках идет речь?
2) Работники не боятся брать ответственность, просто у них нету к этому мотивации. Я раз сказал - так не нужно, будет хуже, два сказал - так не правильно нужно сделать вот так... В третий раз я уже ничего не скажу - хотите так, не вопрос сделаем и так и вот так, как скажите...
2) Работники не боятся брать ответственность, просто у них нету к этому мотивации. Я раз сказал - так не нужно, будет хуже, два сказал - так не правильно нужно сделать вот так... В третий раз я уже ничего не скажу - хотите так, не вопрос сделаем и так и вот так, как скажите...
А вам много раз приходилось видеть проекты спроектированные от начала до конца так, что они рождались в идеальном состоянии, и в нем же жили дальше? Наверное такие проекты и были, но жили они не долго.
Жизнь так устроена, что все меняется. Три месяца назад надо было одно, сейчас немного другое, через еще три месяца надо новые сервисы вводить и под них перекроить часть дизайна и верстки. "Ну это жизнь. Ну надо было" (с) Жванецкий.
Решать подобные задачи — как раз дело профессионалов.
Жизнь так устроена, что все меняется. Три месяца назад надо было одно, сейчас немного другое, через еще три месяца надо новые сервисы вводить и под них перекроить часть дизайна и верстки. "Ну это жизнь. Ну надо было" (с) Жванецкий.
Решать подобные задачи — как раз дело профессионалов.
Вот, вот.
Сегодня одно, завтро другое. Знаем мы этот подход. Тут дело не втом, что вокруг все меняется, а в том, что при проектировании проекта ставились ЛОЖНЫЕ цели. По ходу реализации проекта, чем проект все "реальнее" и ближе к действительности, вот тут и уже начинается метание из угла в угол. Ой все плохо, нужно переделывать, все не то...
Знаем мы таких проектировщиков.
Да, опыт - великая вещь, чем его больше, тем меньше таких заморочек, спланированный проект имеет цель, он последовательно растет и развивается, а не испытывает постоянные непонятные дрязги и метаморфозы.
Сегодня одно, завтро другое. Знаем мы этот подход. Тут дело не втом, что вокруг все меняется, а в том, что при проектировании проекта ставились ЛОЖНЫЕ цели. По ходу реализации проекта, чем проект все "реальнее" и ближе к действительности, вот тут и уже начинается метание из угла в угол. Ой все плохо, нужно переделывать, все не то...
Знаем мы таких проектировщиков.
Да, опыт - великая вещь, чем его больше, тем меньше таких заморочек, спланированный проект имеет цель, он последовательно растет и развивается, а не испытывает постоянные непонятные дрязги и метаморфозы.
А не предполагается, что новые сервисы тоже предварительно проектируются хотя бы в минимальном объеме?
Без разницы через три месяца после запуска или через 3 года. Если речь, конечно, о проектах с долгим жизненным циклом. В таком случае, чем дешевле и быстрее прикручен новый сервис, тем дороже будет поддержка и последующее наращивание.
А вообще для такого спора нужно хоть какие-то данные о проекте привести (это я о посте щас). Рассматривать проблему качества разработки в целом просто смысла не имеет. Юрий бы хоть примерно осведомил общественность о масштабах и условиях чтоли. А то это все круто про слабости ума и прочее, чувствуется наболело у человека, но однако как-то голословно.
Подходы к построению работы и внутрикомандных взаимодействий сильно отличаются в зависимости от параметров проекта. Где-то выгоднее проявить гибкость, минимум правил и несколько ответственных профессионалов. Где-то без определенных затрат на проектирование проект будет слишком дорог в поддержке или вообще развалится на пол дороги. Довольно часто наблюдаю случаи, когда все завязано на ответственности грамотных людей, которой проектную документацию не заменишь. А в таком случае, нет человека - хана проекту.
Без разницы через три месяца после запуска или через 3 года. Если речь, конечно, о проектах с долгим жизненным циклом. В таком случае, чем дешевле и быстрее прикручен новый сервис, тем дороже будет поддержка и последующее наращивание.
А вообще для такого спора нужно хоть какие-то данные о проекте привести (это я о посте щас). Рассматривать проблему качества разработки в целом просто смысла не имеет. Юрий бы хоть примерно осведомил общественность о масштабах и условиях чтоли. А то это все круто про слабости ума и прочее, чувствуется наболело у человека, но однако как-то голословно.
Подходы к построению работы и внутрикомандных взаимодействий сильно отличаются в зависимости от параметров проекта. Где-то выгоднее проявить гибкость, минимум правил и несколько ответственных профессионалов. Где-то без определенных затрат на проектирование проект будет слишком дорог в поддержке или вообще развалится на пол дороги. Довольно часто наблюдаю случаи, когда все завязано на ответственности грамотных людей, которой проектную документацию не заменишь. А в таком случае, нет человека - хана проекту.
Для интересующихся именно условиями можно обратиться к омему блогу.
Некоторые люди тут сразу поняли о чем речь. Те кто не поняли начали доказывать, то тоже умные.
Проектируются и в минимальном объеме, разбиваются на фазы, если план проекта, детальное проектирование по итерациям. Система управления и регистрации ошибок, отдельный ПМ и отдельный аналитик. Т.е. все утчено, всего хватает. Вот бы еще чуть-чуть самостоятельности от непосредственных исполнителей добавить...
Некоторые люди тут сразу поняли о чем речь. Те кто не поняли начали доказывать, то тоже умные.
Проектируются и в минимальном объеме, разбиваются на фазы, если план проекта, детальное проектирование по итерациям. Система управления и регистрации ошибок, отдельный ПМ и отдельный аналитик. Т.е. все утчено, всего хватает. Вот бы еще чуть-чуть самостоятельности от непосредственных исполнителей добавить...
Социология проекта не всегда позволяет полагаться на ответственность отдельных участников.
Можно схему задач применить в качестве инструмента минимизации этих проблем. Ответственность конкретного исполнителя за конкретную задачу и самостоятельность в рамках задачи, постановщика соответственно за исходные данные и прием результата.
Можно схему задач применить в качестве инструмента минимизации этих проблем. Ответственность конкретного исполнителя за конкретную задачу и самостоятельность в рамках задачи, постановщика соответственно за исходные данные и прием результата.
эм... как разработчику можно вменить в ответственность некачественный код, так и конечному руководителю - проблемы в ходе разработки.
мне кажется несколько неэтично руководителю говорить о том, что исполнители недостаточно талантливы или боятся брать на себя ответственность. тем самым он как бы поднимает руки и признает что не может решить свои задачи.
мне кажется это вообще характерная проблема для многих организаций, попытка использовать исполнителей в рабочем процессе, как некие функциональные модули. с людьми надо говорить и говорить часто.
только когда каждый исполнитель увидит что его работу ценят и она значима, он начнет брать на себя ответственность.
ну это просто замечание по теме. не применительно к твоему примеру конечно.
мне кажется несколько неэтично руководителю говорить о том, что исполнители недостаточно талантливы или боятся брать на себя ответственность. тем самым он как бы поднимает руки и признает что не может решить свои задачи.
мне кажется это вообще характерная проблема для многих организаций, попытка использовать исполнителей в рабочем процессе, как некие функциональные модули. с людьми надо говорить и говорить часто.
только когда каждый исполнитель увидит что его работу ценят и она значима, он начнет брать на себя ответственность.
ну это просто замечание по теме. не применительно к твоему примеру конечно.
Если я правильно понял Юрин посыл общественности: если каждый человек делает только что-то одно в своей области и не радеет за проект, то проект получается убогим. Примеров полно. Вроде и дизайн хороший, и верстка какая-то есть, и спрограммирован, и даже контент есть, а проекта нет.
Конечно, суть сводится к грамотному руководству, которое и должно наладить процесс проектирования и грамотного планирования. Но вот уже мой посыл был в том, что какое бы грамотное руководство не было, проект бывает надо часто менять, в условиях смены окружения. И поэтому надо изменения воспринимать нормально и позитивно. И решать те вопросы, которые нужно добиться изменениями.
Конечно, суть сводится к грамотному руководству, которое и должно наладить процесс проектирования и грамотного планирования. Но вот уже мой посыл был в том, что какое бы грамотное руководство не было, проект бывает надо часто менять, в условиях смены окружения. И поэтому надо изменения воспринимать нормально и позитивно. И решать те вопросы, которые нужно добиться изменениями.
По моему описаны типичные грабли при организации работы над проектом (в данном случае Web). Хочется пожелать автору удачи и успехов и сказать что одним перекладыванием ответственности здесь обойдешься.
На мой взгляд с таким подходом первостепенной является организация процесса таким образом чтобы исключить возможные ошибки и проблемы например с помощью подходов принятых в дисциплине управления качеством. В том числе засчет выбора инструментов, вроде фреймворков, а также каких-то lesson learned - для следующих проетков. Отсутствие инструкций или гайдлайнов - это не то к чему надо стремится, удачные практики надо как-то систематизировать, да и для вхождения новых людей эти штуки поначалу могут здорово помогать.
Повышение ответственности и мотивации - скорее как общий вектор.
На мой взгляд с таким подходом первостепенной является организация процесса таким образом чтобы исключить возможные ошибки и проблемы например с помощью подходов принятых в дисциплине управления качеством. В том числе засчет выбора инструментов, вроде фреймворков, а также каких-то lesson learned - для следующих проетков. Отсутствие инструкций или гайдлайнов - это не то к чему надо стремится, удачные практики надо как-то систематизировать, да и для вхождения новых людей эти штуки поначалу могут здорово помогать.
Повышение ответственности и мотивации - скорее как общий вектор.
Потрудитесь прочитать комментарии выше. Про перекладывание ответсвенности речи тут вообще не идет!
С комментария выше:
> Просто они бояться что взяв отвественность "получат по шапке".
Для меня это выглядит так: менеджер который формально отвечает за успех проекта предлагает участникам быть более ответственными и в большей мере вместе с менеджером отвечать за успех. Вместо слова "перекладывание" можно использовать "делегирование ответственности". На мой взгляд - это абсолютно нормальная практика, вот только разным людям можно доверить разное количество ответственности. Это нисколько не отменяет работы над процессом.
А вообще странно, что работники боятся получить по шапке. Ну пускай подойдут спросят первые раз пять, или обстановка к этому не располагает? Может действительно мотивации нет.
> Просто они бояться что взяв отвественность "получат по шапке".
Для меня это выглядит так: менеджер который формально отвечает за успех проекта предлагает участникам быть более ответственными и в большей мере вместе с менеджером отвечать за успех. Вместо слова "перекладывание" можно использовать "делегирование ответственности". На мой взгляд - это абсолютно нормальная практика, вот только разным людям можно доверить разное количество ответственности. Это нисколько не отменяет работы над процессом.
А вообще странно, что работники боятся получить по шапке. Ну пускай подойдут спросят первые раз пять, или обстановка к этому не располагает? Может действительно мотивации нет.
2 h1 в документе быть не должно! ;)
по сути, юра, ты прав, но если вернуться, мне кажется, что пост написан под впечатлением разработки TMS2, я прав? точнее, это могло стать последней каплей =)
по сути, юра, ты прав, но если вернуться, мне кажется, что пост написан под впечатлением разработки TMS2, я прав? точнее, это могло стать последней каплей =)
Технократия не за горами!!! Фактически главными в проектах становятся уже не владельцы капитала, а рядовые интеллектуальные наемные сотрудники. И дело не в юридических нюансах, а в фактической связи создателя и создания :)
Мы в такой ситуации можем диктовать наши условия бизнесу :)
Мы в такой ситуации можем диктовать наши условия бизнесу :)
От руководителя требуется либо глубокое понимание процессов, либо глубокое понимание людей, которые над ними работают.
Статья определенно для второго типа руководителей. Кстати именно такие руководители достигают наибольших высот в силу своей универсальности.
Статья определенно для второго типа руководителей. Кстати именно такие руководители достигают наибольших высот в силу своей универсальности.
Хм... дальше первого примера не стал читать. Почему автор текста слепо предполагает, что я должен обрамлять h1 в див, чтоб слегка его изменить? Я не гуру в верстке, но первое что пришло в голову, что я бы просто повесил на h1 немного другой класс. По-моему любой верстальщик сначала попробует достичь эффекта средствами CSS, не пихая redundant HTML тэги по поводу и без повода.
<h1 class='alt'>Восстановление пароля</h1>
h1.alt {
font-size: 16px;
font-weight:bold;
padding:6px 0pt 4px 14px;
margin:0pt;
}
PS. Кстати, болд излишний, ибо в h1 он идет по умолчанию (: Другое дело если бы было: font-weight: normal; (:
<h1 class='alt'>Восстановление пароля</h1>
h1.alt {
font-size: 16px;
font-weight:bold;
padding:6px 0pt 4px 14px;
margin:0pt;
}
PS. Кстати, болд излишний, ибо в h1 он идет по умолчанию (: Другое дело если бы было: font-weight: normal; (:
Вообще-то пост размещен в блоге по "Управлении проектами".
И пост про людей, а не про теги. Потрудитесь прочитать еще 2 примера.
И пост про людей, а не про теги. Потрудитесь прочитать еще 2 примера.
Я понимаю в каком это разделе, но вы изначально предполагаете, что проектом будут заниматся плохие специалисты. Если сначала нанять хороших, то может и статью не пришлось бы писать. И я не буду дочитывать статью, потому что не вижу в этом никакого смысла. Точно так же я не читаю литературу, если в ней нарушено логичное обоснование происходящего. Если главный герой, вместо того чтобы посмотреть порядковый номер Урана или Плутона вбивает в поисковик "Уран Плутон Ядерные бомбы", вместо того чтобы открыть таблицу Менделеева (Д.Браун "Цифровая крепость")...
У нас работают отличные специалисты. А если вы не поняли проблему, то мне это сугубо фиолетово.
Я так понимаю Дену Брауну вы тоже письмо написали о том, что не будете дочитывать его роман до конца?
Я так понимаю Дену Брауну вы тоже письмо написали о том, что не будете дочитывать его роман до конца?
Ну если я не понял проблему, значит вы плохо излагаете (; О чем собственно я и говорю с самого начала. Приводите корректные примеры, заинтересовывайте читателя читать дальше. Я как читатель, не обязан пробиваться к сути написаного. Если я вижу, что приведенный пример небрежен и непродуман, я перестаю читать (делая предположение, что возможно и вся статья написана в таком ключе; тем более, что тут не 5 печатных страниц формата А4).
ЗЫ. И если бы Ден Браун запостил роман в соц.сеть, которую я читаю и оставляю коментарии, то да, написал бы (:
ЗЫ. И если бы Ден Браун запостил роман в соц.сеть, которую я читаю и оставляю коментарии, то да, написал бы (:
Но вообще-то человек прав. Во всём, кроме того, что не стал дочитывать.
Увидев, что "хороший верстальщик, понимающий каскадную таблицу стилей" добавляет заголовку обёртку - несколько опешила.
Так что пример правда о том, как чья-то ошибка нарастает снежным комом. А именно об этом, кажется, в статье и говорится) Спасибо, интересно было почитать.
Увидев, что "хороший верстальщик, понимающий каскадную таблицу стилей" добавляет заголовку обёртку - несколько опешила.
Так что пример правда о том, как чья-то ошибка нарастает снежным комом. А именно об этом, кажется, в статье и говорится) Спасибо, интересно было почитать.
Опоздал с прочтением — уже не могу поставить статье плюс, а жаль.
"Когда через несколько недель после начала сборки проекта до проекта добираются тестировщики..." - после этого можно не читать.
Очень узнаваемая ситуация. На мой взгляд, в том нашем случае проблема была в искусственной разорванности и жесткости процесса: верстальщику приходил уже утвержденный макет, который требовалось воспроизвести с очень высокой точностью, но при этом и дизайнер и программист имели посредственное представление о принципах верстки, в результате чего html-код изначально переусложнялся без реальной надобности, и программист путался в нем еще легче; верстальщик оказывался меж двух огней и, фактически, исправлял каждое вмешательство программиста в код, отчего все участники раздражались, а работа буксовала. Разделение труда было мнимым.
На мой взгляд, для дизайнера может быть весьма отрезвляющим мнение верстальщика, поскольку он работает в первую очередь со структурой страницы, и может оказать дизайнеру неоценимую услугу своими советами по унификации элементов интерфейса. Я вообще предпочитаю модель wireframe-дизайна с последующим оформлением.
Короче говоря, очень глупо пренебрегать взаимодействием специалистов на этапе проектирования интерфейса.
На мой взгляд, для дизайнера может быть весьма отрезвляющим мнение верстальщика, поскольку он работает в первую очередь со структурой страницы, и может оказать дизайнеру неоценимую услугу своими советами по унификации элементов интерфейса. Я вообще предпочитаю модель wireframe-дизайна с последующим оформлением.
Короче говоря, очень глупо пренебрегать взаимодействием специалистов на этапе проектирования интерфейса.
Как только заказов стало больше. Я решил серьезно занятся подключением в проекты других разработчиков (фриланс).
И тут столкнулся именно с описанной проблемой халатности или так сказать не моя забота как там будет потом.
Есть у меня очень тяжелый пример проекта, в котором принимали участие 1 дизайнер, 1 (потом уже 2) верстальщика, 4 программиста. По сути, мог бы все собрать/реализовать сам. Не настолько тяжелый был проект.
Получилась в итоге каша, смесь, баги которой я отлавливал по сей день и они, к сожалению, еще не закончились.
Мое понимание профессионала/идеала, человека в команде:
Дизайнер. Знает как делать дизайн который легко описывается css, где можно применить оптимизацию чтобы не плодить лишние блоки с разными классами.
Есть, например, дизайнеры, в макеты внедряют шрифты не использующиеся на вэбе, как основной текст. А неграмотный заказчик требует как на эскизе. И это только один из сотни примеров. Мне приходилось такое верстать, что сам черт ногу сломает, а не программист. Стараюсь или отказаться, или переубедить заказчика с последующими правками дизайнером.
Верстальщик. Он же основное связующее звено между программистом и дизайнером. Понимать и то, и то. Обязан.
Программист. Понять, что дал ему верстальщик и сразу указать на баги. Где-то вмешаться самому. Требовать от дизайнера, верстальщика, менеджера (нужное подчеркнуть) полного объема материала/прототипа про проекту с уже отловленными багами. Своих хватит.
Только такая гремучая смесь может минимизировать риски.
И тут столкнулся именно с описанной проблемой халатности или так сказать не моя забота как там будет потом.
Есть у меня очень тяжелый пример проекта, в котором принимали участие 1 дизайнер, 1 (потом уже 2) верстальщика, 4 программиста. По сути, мог бы все собрать/реализовать сам. Не настолько тяжелый был проект.
Получилась в итоге каша, смесь, баги которой я отлавливал по сей день и они, к сожалению, еще не закончились.
Мое понимание профессионала/идеала, человека в команде:
Дизайнер. Знает как делать дизайн который легко описывается css, где можно применить оптимизацию чтобы не плодить лишние блоки с разными классами.
Есть, например, дизайнеры, в макеты внедряют шрифты не использующиеся на вэбе, как основной текст. А неграмотный заказчик требует как на эскизе. И это только один из сотни примеров. Мне приходилось такое верстать, что сам черт ногу сломает, а не программист. Стараюсь или отказаться, или переубедить заказчика с последующими правками дизайнером.
Верстальщик. Он же основное связующее звено между программистом и дизайнером. Понимать и то, и то. Обязан.
Программист. Понять, что дал ему верстальщик и сразу указать на баги. Где-то вмешаться самому. Требовать от дизайнера, верстальщика, менеджера (нужное подчеркнуть) полного объема материала/прототипа про проекту с уже отловленными багами. Своих хватит.
Только такая гремучая смесь может минимизировать риски.
"Бумажки-инструкции, четкое следование административной иерархии — это признаки слабости ума и таланта".
Чётко и правдиво. Спасибо за разбор и выводы! (спустя 16 лет, ахах)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного об ответственности и обязанностях