Pull to refresh
0
0
Yurganov @yurganov

User

Обращаю внимание на следующие аспекты:

1. Соблюдение договоренностей(в том числе не формальных) по ТЗ.

Случалось, что согласовывали одно, по факту человек делал другое. Почему? Потому что ему проще сейчас с тобой согласиться… а дальше делать как угодно. Это определенно проблема того, кто ставит задачу и лечиться прояснением ситуации с коллегой, в следущий раз человек явно высказывает свою позицию и исполняемое решение имеет действительно двухсторонний комитмент.

2. Самостоятельность — умение программиста преодаливать технические сложности реализации, не бояться совершать ошибки на пути поиска возможных решений.

3. Интерактивность. Случается «залипание» на задачах и есть разработчики, которые сообщат о возникших трудностях, есть и те, кто будут сидеть с проблемой пока сам не поинтересуешься прогрессом.

4. Умение формулировать проблему в технических терминах. Может показаться странным, но случается, что разработчик начинает говорить о коде и багах системы как о каких то монстрах, задача которых его запутать или одурачить. Помогают перерывы или выяснение действительных причин проблем в диалоге.

5. Ответсвенность. Определенно плюсом для разработчика, если он не просто передал задачу на тестирование(а случается что и об этом возникает необходимость напомнить), но к примеру может подойти к тестировщику и поинтересоваться, что там с его задачей(бывает что тестировщик нашел баг, но по ошибке заасайнил на другого и считай задача встала).
Спасибо — по делу.

добавлю:
Быть внимательным к команде. Особенно к ключевым ее участникам.

Интеграция важней производства. Выпуская быстрые прототипы, мы выступаем в роли интегратора существующих технологий для конечного потребителя продукта. Важней оценить потребности клиента и то, как ваша отрасль может их удволетворить, если говорить о рынке заказного ПО(в том числе сайты), то это могут быть существующие opensource-решения, решения сторонних компаний. Наша задача понять, чего не хватает и вот тут пригодится производство.
Как создать драйвер с определенным профилем через вашу обертку?
да не только социалок, но фиддер от этого не перестает быть фидером

для задач корпоративного адрессбуков я бы как пользователь предпочел сервис по синхронизации нативной книги ифона с информацией по конторе(только умную синхронизацию чтобы клонов не добавляла если человек уже есть)
-что для прототипирования UI кстати используете? после сразу перегоняете на натив или делаете на html5?
-nosql выбрана действительно из-за специфики типа источников/данных или больше сказывается иннерция от того, что использовала компания для решения предыдущих задач(читай квалификации сотрудников)? есть ли какой-то опыт почему sql-решения не подходят(желательно проценты производительности, нагрузки систем на опыте реализованных проектов)?
Привет, смотрите у вас тут два концепта:
1) Корпоративный фиддер социалок
2) Адресбук истбанка

Просто забудьте про второй, сделайте первый на пятерку второй можно следующим проектом/итерацией/отдельным приложением(по ресурсам эффективней, более четкий фокус на функциях продукта)

1) Стилистика, сейчас пестрота — порой сложно разобрать текст, все цвета радуги(понимаю что хотелось подчеркнуть индивидуальность социалки)
2) На русском или английском? — выберите один формат, выделите роль копирайтера(про «Facebook-лента» «Твиттер-лента»; «Новости вконтакте» — почему то с маленькой буквы)
3) В фиддере как правило читаешь что сегодня, вчера, максимум — неделя,
значит то место, что у вас отведено под даты(включая год) — просто съедает пиксели(шум)

пример
1.bp.blogspot.com/-wJ2jKTDYg0w/UV3dMwueJXI/AAAAAAAAATw/i4si3ULKlQk/s1600/mock.png
В моем кейсе оказался бональный логаут, а корзина по кукам показывалась с реальными ценами. А books.ru спасибо за предоставленную возможность.
вчера в корзине книжка была по рублю сегодня по 143, тоже с остальными(цены превратилсь в реальные), при этом сама акция видимо продолжается, тк можно другие книги по своей цене добавить 0_0

С месяц на руках prs 900, нареканий по формфактору и функциям чтения нет, но вот корпус начал поскрипывать где-то на второй недели.
за книжки на safaribooksonline.com платежи проходят?
На ласт заходите, ищите нужный трек и вперёд. (http://www.lastfm.ru/)
у меня заработал после изменения настроек на grooveshark.com

при этом когда сеты на vpleer.ru — страница вообще не загружается
vkontakte.ru звук не идёт

*система такая же
Липучка действительно удобная, у меня ей биты от перфоратора перетянуты;)
С закачиком должен общаться не дизайнер или разработчик, а менеджер.
Именно он отвечает за управление требованиями заказчика.
*в случае, когда он по совместительству не является дизайнером/девелопером ему проще работать с критикой клиента(не так эго задевает)

Как вы определяете, что вам зубы починили?
Правильно, больше не болят/дырки заплобировали/пятна удалили.

Почему вы не выхватываете бур.машинку у дантиста во время сеанса, чтобы себе вот тут подправить неровность зуба?
Правльно, вы не умеете работать бур.машинкой да и некоторых просто в дрожь от неё бросает.

Почему когда у вас машина не заводится и вы не механик, то, отдавая её мастеру, доверяете ему определение неисправности и например замену свечей/efi/бензонасоса
Правильно, потому что он понимает в своей работе, а вы определяете результат его работы по тому, что машина поехала.


В приведёных примерах определение «правльности» работ естественно вытекает из проблемы(задачи) болел зуб/перестал болеть машина не ехала/поехала в доме нет полов/через неделю вы отбиваете чечётку.

По-моему здесь проблема прозрачности. Когда клиент, а бывает и вы не понимаете когда же будет считаться, что работа выполнена/Как организрваны ревью с клиентом и каким образом предусмотренны внесение изменений в проект?..
Клиент видит картинку/шрифт/размер и он высказывает свое мнение — он(физически) может оценить(это же гораздо проще чем удалить нерв и заплобировать канал). И он ведь деньги платит, а значит и музыку заказывает, ведь так?
Так оно так, если всё ваше общение — это вы узнали чего он хочет и молча, взяв %предоплату отправились выполнять заказ, а потом через пару недель начинают проклювываться интересные подробности…

Чем прозрачней будет схема ваших отношений, тем проще разрешать спорные ситуаци. И лучше если это произойдёт ещё на берегу.
Клиент это всегда двухстороннее общение и помимому требований клиента есть и требования исполнителя(только так он может отвечать за результат), если заказчик этого не понимает или у вас так и не получилось ему это доходчиво донести стоит задуматься нужен ли вам этот заказчик/верна ли ваша схема работы(читай квалификация)
*и не забываем отражать в договоре нужные акценты, например число макетов/схему оплаты/схему вненсений изменений

Клиент не идиот он клиент.
По-моему изящное решение.
Завидное будущее, один судорожно выбивает настройки бубc и так чтоб поинтересней, вторая же — цензоред.
И теперь при встрече с женщиной твой взгляд будет не на груди или глазах, а где-то там в пустоту над головой.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity