1. Соблюдение договоренностей(в том числе не формальных) по ТЗ.
Случалось, что согласовывали одно, по факту человек делал другое. Почему? Потому что ему проще сейчас с тобой согласиться… а дальше делать как угодно. Это определенно проблема того, кто ставит задачу и лечиться прояснением ситуации с коллегой, в следущий раз человек явно высказывает свою позицию и исполняемое решение имеет действительно двухсторонний комитмент.
2. Самостоятельность — умение программиста преодаливать технические сложности реализации, не бояться совершать ошибки на пути поиска возможных решений.
3. Интерактивность. Случается «залипание» на задачах и есть разработчики, которые сообщат о возникших трудностях, есть и те, кто будут сидеть с проблемой пока сам не поинтересуешься прогрессом.
4. Умение формулировать проблему в технических терминах. Может показаться странным, но случается, что разработчик начинает говорить о коде и багах системы как о каких то монстрах, задача которых его запутать или одурачить. Помогают перерывы или выяснение действительных причин проблем в диалоге.
5. Ответсвенность. Определенно плюсом для разработчика, если он не просто передал задачу на тестирование(а случается что и об этом возникает необходимость напомнить), но к примеру может подойти к тестировщику и поинтересоваться, что там с его задачей(бывает что тестировщик нашел баг, но по ошибке заасайнил на другого и считай задача встала).
добавлю:
Быть внимательным к команде. Особенно к ключевым ее участникам.
Интеграция важней производства. Выпуская быстрые прототипы, мы выступаем в роли интегратора существующих технологий для конечного потребителя продукта. Важней оценить потребности клиента и то, как ваша отрасль может их удволетворить, если говорить о рынке заказного ПО(в том числе сайты), то это могут быть существующие opensource-решения, решения сторонних компаний. Наша задача понять, чего не хватает и вот тут пригодится производство.
да не только социалок, но фиддер от этого не перестает быть фидером
для задач корпоративного адрессбуков я бы как пользователь предпочел сервис по синхронизации нативной книги ифона с информацией по конторе(только умную синхронизацию чтобы клонов не добавляла если человек уже есть)
-что для прототипирования UI кстати используете? после сразу перегоняете на натив или делаете на html5?
-nosql выбрана действительно из-за специфики типа источников/данных или больше сказывается иннерция от того, что использовала компания для решения предыдущих задач(читай квалификации сотрудников)? есть ли какой-то опыт почему sql-решения не подходят(желательно проценты производительности, нагрузки систем на опыте реализованных проектов)?
Привет, смотрите у вас тут два концепта:
1) Корпоративный фиддер социалок
2) Адресбук истбанка
Просто забудьте про второй, сделайте первый на пятерку второй можно следующим проектом/итерацией/отдельным приложением(по ресурсам эффективней, более четкий фокус на функциях продукта)
1) Стилистика, сейчас пестрота — порой сложно разобрать текст, все цвета радуги(понимаю что хотелось подчеркнуть индивидуальность социалки)
2) На русском или английском? — выберите один формат, выделите роль копирайтера(про «Facebook-лента» «Твиттер-лента»; «Новости вконтакте» — почему то с маленькой буквы)
3) В фиддере как правило читаешь что сегодня, вчера, максимум — неделя,
значит то место, что у вас отведено под даты(включая год) — просто съедает пиксели(шум)
вчера в корзине книжка была по рублю сегодня по 143, тоже с остальными(цены превратилсь в реальные), при этом сама акция видимо продолжается, тк можно другие книги по своей цене добавить 0_0
С закачиком должен общаться не дизайнер или разработчик, а менеджер.
Именно он отвечает за управление требованиями заказчика.
*в случае, когда он по совместительству не является дизайнером/девелопером ему проще работать с критикой клиента(не так эго задевает)
Как вы определяете, что вам зубы починили?
Правильно, больше не болят/дырки заплобировали/пятна удалили.
Почему вы не выхватываете бур.машинку у дантиста во время сеанса, чтобы себе вот тут подправить неровность зуба?
Правльно, вы не умеете работать бур.машинкой да и некоторых просто в дрожь от неё бросает.
Почему когда у вас машина не заводится и вы не механик, то, отдавая её мастеру, доверяете ему определение неисправности и например замену свечей/efi/бензонасоса
Правильно, потому что он понимает в своей работе, а вы определяете результат его работы по тому, что машина поехала.
…
В приведёных примерах определение «правльности» работ естественно вытекает из проблемы(задачи) болел зуб/перестал болеть машина не ехала/поехала в доме нет полов/через неделю вы отбиваете чечётку.
По-моему здесь проблема прозрачности. Когда клиент, а бывает и вы не понимаете когда же будет считаться, что работа выполнена/Как организрваны ревью с клиентом и каким образом предусмотренны внесение изменений в проект?..
Клиент видит картинку/шрифт/размер и он высказывает свое мнение — он(физически) может оценить(это же гораздо проще чем удалить нерв и заплобировать канал). И он ведь деньги платит, а значит и музыку заказывает, ведь так?
Так оно так, если всё ваше общение — это вы узнали чего он хочет и молча, взяв %предоплату отправились выполнять заказ, а потом через пару недель начинают проклювываться интересные подробности…
Чем прозрачней будет схема ваших отношений, тем проще разрешать спорные ситуаци. И лучше если это произойдёт ещё на берегу.
Клиент это всегда двухстороннее общение и помимому требований клиента есть и требования исполнителя(только так он может отвечать за результат), если заказчик этого не понимает или у вас так и не получилось ему это доходчиво донести стоит задуматься нужен ли вам этот заказчик/верна ли ваша схема работы(читай квалификация)
*и не забываем отражать в договоре нужные акценты, например число макетов/схему оплаты/схему вненсений изменений
1. Соблюдение договоренностей(в том числе не формальных) по ТЗ.
Случалось, что согласовывали одно, по факту человек делал другое. Почему? Потому что ему проще сейчас с тобой согласиться… а дальше делать как угодно. Это определенно проблема того, кто ставит задачу и лечиться прояснением ситуации с коллегой, в следущий раз человек явно высказывает свою позицию и исполняемое решение имеет действительно двухсторонний комитмент.
2. Самостоятельность — умение программиста преодаливать технические сложности реализации, не бояться совершать ошибки на пути поиска возможных решений.
3. Интерактивность. Случается «залипание» на задачах и есть разработчики, которые сообщат о возникших трудностях, есть и те, кто будут сидеть с проблемой пока сам не поинтересуешься прогрессом.
4. Умение формулировать проблему в технических терминах. Может показаться странным, но случается, что разработчик начинает говорить о коде и багах системы как о каких то монстрах, задача которых его запутать или одурачить. Помогают перерывы или выяснение действительных причин проблем в диалоге.
5. Ответсвенность. Определенно плюсом для разработчика, если он не просто передал задачу на тестирование(а случается что и об этом возникает необходимость напомнить), но к примеру может подойти к тестировщику и поинтересоваться, что там с его задачей(бывает что тестировщик нашел баг, но по ошибке заасайнил на другого и считай задача встала).
добавлю:
Быть внимательным к команде. Особенно к ключевым ее участникам.
Интеграция важней производства. Выпуская быстрые прототипы, мы выступаем в роли интегратора существующих технологий для конечного потребителя продукта. Важней оценить потребности клиента и то, как ваша отрасль может их удволетворить, если говорить о рынке заказного ПО(в том числе сайты), то это могут быть существующие opensource-решения, решения сторонних компаний. Наша задача понять, чего не хватает и вот тут пригодится производство.
для задач корпоративного адрессбуков я бы как пользователь предпочел сервис по синхронизации нативной книги ифона с информацией по конторе(только умную синхронизацию чтобы клонов не добавляла если человек уже есть)
-nosql выбрана действительно из-за специфики типа источников/данных или больше сказывается иннерция от того, что использовала компания для решения предыдущих задач(читай квалификации сотрудников)? есть ли какой-то опыт почему sql-решения не подходят(желательно проценты производительности, нагрузки систем на опыте реализованных проектов)?
1) Корпоративный фиддер социалок
2) Адресбук истбанка
Просто забудьте про второй, сделайте первый на пятерку второй можно следующим проектом/итерацией/отдельным приложением(по ресурсам эффективней, более четкий фокус на функциях продукта)
1) Стилистика, сейчас пестрота — порой сложно разобрать текст, все цвета радуги(понимаю что хотелось подчеркнуть индивидуальность социалки)
2) На русском или английском? — выберите один формат, выделите роль копирайтера(про «Facebook-лента» «Твиттер-лента»; «Новости вконтакте» — почему то с маленькой буквы)
3) В фиддере как правило читаешь что сегодня, вчера, максимум — неделя,
значит то место, что у вас отведено под даты(включая год) — просто съедает пиксели(шум)
пример
1.bp.blogspot.com/-wJ2jKTDYg0w/UV3dMwueJXI/AAAAAAAAATw/i4si3ULKlQk/s1600/mock.png
при этом когда сеты на vpleer.ru — страница вообще не загружается
vkontakte.ru звук не идёт
*система такая же
Именно он отвечает за управление требованиями заказчика.
*в случае, когда он по совместительству не является дизайнером/девелопером ему проще работать с критикой клиента(не так эго задевает)
Как вы определяете, что вам зубы починили?
Правильно, больше не болят/дырки заплобировали/пятна удалили.
Почему вы не выхватываете бур.машинку у дантиста во время сеанса, чтобы себе вот тут подправить неровность зуба?
Правльно, вы не умеете работать бур.машинкой да и некоторых просто в дрожь от неё бросает.
Почему когда у вас машина не заводится и вы не механик, то, отдавая её мастеру, доверяете ему определение неисправности и например замену свечей/efi/бензонасоса
Правильно, потому что он понимает в своей работе, а вы определяете результат его работы по тому, что машина поехала.
…
В приведёных примерах определение «правльности» работ естественно вытекает из проблемы(задачи) болел зуб/перестал болеть машина не ехала/поехала в доме нет полов/через неделю вы отбиваете чечётку.
По-моему здесь проблема прозрачности. Когда клиент, а бывает и вы не понимаете когда же будет считаться, что работа выполнена/Как организрваны ревью с клиентом и каким образом предусмотренны внесение изменений в проект?..
Клиент видит картинку/шрифт/размер и он высказывает свое мнение — он(физически) может оценить(это же гораздо проще чем удалить нерв и заплобировать канал). И он ведь деньги платит, а значит и музыку заказывает, ведь так?
Так оно так, если всё ваше общение — это вы узнали чего он хочет и молча, взяв %предоплату отправились выполнять заказ, а потом через пару недель начинают проклювываться интересные подробности…
Чем прозрачней будет схема ваших отношений, тем проще разрешать спорные ситуаци. И лучше если это произойдёт ещё на берегу.
Клиент это всегда двухстороннее общение и помимому требований клиента есть и требования исполнителя(только так он может отвечать за результат), если заказчик этого не понимает или у вас так и не получилось ему это доходчиво донести стоит задуматься нужен ли вам этот заказчик/верна ли ваша схема работы(читай квалификация)
*и не забываем отражать в договоре нужные акценты, например число макетов/схему оплаты/схему вненсений изменений
Клиент не идиот он клиент.