Это не оплаченный рекламный обзор, просто многие интересуются – а чем же мы (компания) все-таки занимаемся, к сожалению, не все проекты мы можем выставить на показ, так что продемонстрировать хоть что-то – это уже достижение

Таки возвращаясь к проекту – Tuuube – проект, по сути, являющийся каталогом сайтов. Каталог предполагает быть “белым” и “пушистым”:

• размещение сайта – платное за мизерную сумму (участие в бета тестировании дает нам N-ую сумму на баланс)
• прозрачный поиск – его алгоритм понятен каждому – поиск происходит по кейвордам указанными web-мастерами
• есть обратная связь от посетителей к системе – это рейтинги да репорты

Основная идея проекта – создать каталог сайтов, с “прозрачным” поиском, который позволит легко и не дорого заполучить на сайт свою долю пользователей, и это без каких либо дополнительных затрат на оптимизацию под поисковые системы. Так же, владелец сайта может сам выбрать в каком виде преподнести свой сайт – изменять можно все – название, описание, ключевые слова, изображения и т.д…

Внешний вид нашего творения:

Еще одной фишкой проекта является указание определения слов – т.е. если мы ищем “apple” – подразумевая фрукт, то достаточно кликнуть по слову и указать данное значение, таким образом “Apple”, за который болеет Стив Джобс, будет ниже в поисковой выдаче нежели фруктовые компании…

Еще пару слов о заказчике:

Alain Villenave – прикольный и доброжелательный человек, адекватен, обладает хорошим чувством юмора. Перед стартом проекта приезжал к нам и рассказывал о своих идеях. Обладает хорошим терпением, на кое грех жаловаться.

Выскажу ИМХО о недостатках, какие вижу:

• Дизайн – достаточно спорный момент – заказчик сам сидел на голове своего же дизайнера, и наша задача сводилась к интеграции – но мне он не совсем нравится
• Как мне кажется, слишком усложнили систему подсчетов оплаты сайтов, бонусов и т.д. – даже видя перед собой алгоритм подсчета мне не кажется эта система такой прозрачной, как сам поиск

Если у кого есть какие пожелание и мнения о проекте – прошу высказываться…

Другие посты на эту тему

• No Related Post

Если совещания среди Ваших коллег или подчиненных превращаются в балаган, то значит, пора предпринимать решительные меры…

Я не привожу универсального рецепта, ибо его нет, я не буду вдаваться в мельчайшие тонкости – т.к. их можно перечислять до бесконечности, я лишь описываю моё виденье данного вопроса…

Для себя я совещания разделяю на несколько типов (примечания не привязаны строго к типу):

1. “Пятиминутки” – т.е. это плановое совещание по расписанию, многие считают их бесполезными, но они способствуют поддержанию дисциплины
   

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

2. Заранее планируемое совещание для обсуждения каких-либо проблем/дилемм/…леммм
   

   • Определите цель вашего совещания – без цели – совещание превратиться в броуновское движение общение
   • Разошлите всем участникам повестку дня – старайтесь избегать обобщенных расплывчатых фраз – больше конкретики
   • Если у Вас есть материал для изучения – его так же лучше предоставить заранее – иначе Ваше совещание превратится в избу-читальню
   • Определите время и место проведения совещания – чем раньше участники узнают о своём участии тем лучше – ведь не только у Вас могут быть планы
   • Если предполагается обсуждение нескольких вопросов – ограничьте каждый из них по времени
   • Избегайте пересечения времени проведения совещания с обеденным перерывом иль с окончанием рабочего дня – иначе совещание будет похоже на последнюю пару в институте – все ждут окончания сего действа, абсолютно не вникая в суть происходящего
   • Если совещание затянется на пару часов – запланируйте перерывы – ведь все мы люди, все мы человеки
   • Определите список участников – если их больше 20-ти человек – вероятно, его лучше сократить (стоит попробовать японский “нью-маваши” – т.е. вначале проводятся совещания мелких групп, затем представители групп участвуют в главном совещании) – чем больше людей – тем больше вероятность неконтролируемых дискуссий между участниками
   • Записывайте достигнутые результаты (ведите протокол т.н. “meeting minutes”) – иначе смысла нет в самом собрании
   • По завершению – огласите “итого” дабы все участники понимали добежали ли Вы до финиша
   • Не затягивайте совещание – заканчивайте в строго оговоренное время, остались вопросы – назначайте новое
   • После часа совещания – вероятность получить результат будет стремиться к нулю

3. Обучение – т.е. формат конференции – есть докладчик(и), и он задает тон собранию
   

   • У Вас, как докладчика, должен быть составлен план предстоящего совещания – дабы не уйти от сути
   • Отрепетируйте свой доклад, если Вы первый раз выступаете с ним
   • Подготовьте наглядный материал для доклада – ибо один раз увидеть всё же лучше, чем сто раз услышать (вредные советы от “самизнаетекого” )
   • Подготовьте раздаточный материал – в нем может быть написан лишь Ваш план совещания, но пометки оставленные на полях такого материала могут иногда оказаться бесценными, а еще они всегда помогут освежить память

4. “Мозговой штурм” – достаточно специфический тип совещаний, направлен на решение не тривиальной задачи
   

   • Огласите участникам лишь тему обсуждения, не углубляйтесь в подробности, нужен именно штурм, а не зацикливание на поиске “самого-самого” решения
   • Приготовьтесь записывать все высказанные мысли участников
   • Никогда не критикуйте предлагаемые решения (и пресекайте подобное со стороны коллег)

5. “Ни рыба ни мясо” – спонтанные совещания аля в курилке, за кофе, начинаются фразой – “О, как хорошо что Вы все здесь, я давно хотел с Вами обсудить …”
   

   • Редко бывают конструктивными, и отношение к ним соответствующее
   • Ни к чему не обязывает участников – т.е. что-бы Вы не решили – это не будет воспринято как руководство к действию
   • Иногда имеют эффект “мозгового штурма” – за что их и любят – вроде и не работал, а что-то таки порешалось (главное – потом не забыть, что именно было решено)

А теперь вернемся к балагану который устраивают ярые спорщики, дабы их унять нам потребуется составить правила поведения на совещаниях и придерживаться их (а так же принуждать остальных к соблюдению правил):

1. Никто, и ни при каких обстоятельствах не перебивает выступление
   • Если появляется вопрос – поднимаем руку
   • Если их становится всё больше – берем ручку и записываем в блокнотик (как у Вас его нет? а зачем Вы сюда пришли?)
2. Докладчик заканчивает своё выступление какой-либо контрольной фразой иль словом (к примеру, dixi (лат.) – “Я сказал”)
3. После окончания доклада, все желающие задают вопросы
4. За “очередью” вопросов должен следить либо “арбитр”, назначенный заранее, либо сам докладчик
5. Возможно, следует принять условия, при которых докладчик таки прерывает своё выступление – к примеру задавать вопросы хотят уже все присутствующие
6. Возможно, Вам следует применить приём именуемый “мячик выступающего” – т.е. говорит только тот, у кого мячик в руках

И еще небольшой совет: пользуйтесь органайзерами – благо они сейчас есть практически в каждом телефоне (кпк), а синхронизация с компьютером занимает меньше минуты – зато Ваш девайс всегда с Вами и он всегда напомнит, что Вас где-то ждут. А если Вы и все Ваши коллеги пользуетесь Outlook’ом – то Вы сможете легко проинформировать их о совещании и соответствующая информация ляжет в их органайзеры (см. http://office.microsoft.com/ru-ru/outlook/HA012293681049.aspx#2).

Ссылки по теме:

• http://www.elitarium.ru/2007/10/12/provedenie_soveshhanija.html
• http://www.stepconsulting.ru/publ/3.shtml

Другие посты на эту тему

• No Related Post

Конечно ранг разработчика – это достаточно абстрактное понятие, но я выскажу свое мнение по данному вопросу, оно не привязано ни к какой теории, а базируется лишь на моём опыте.

Junior Developer

• оптимист, всегда недооценивает поставленную задачу
• постоянно ощущает нехватку времени
• стесняется показать свое незнание
• постоянно наступает на грабли
• с трудом доводит проект до финальной точки
• тестер – враг – ибо находит баги
• менеджер – не воспринимается еще всерьез
• пока не ориентируется по ЗП, но если ему предложат на $50 больше в другом месте – может уйти
• рутинную работу считает сложной, но должен справляться

Developer

• пессимист, зачастую недооценивает свои силы и боится промахнуться в оценке
• всегда есть время на перекур и чашечку кофе
• не стесняется спрашивать у коллег по цеху, может даже нагло их эксплуатировать
• наступает только на грабли спрятанные в высокой траве
• скрипя зубами доводит проект до ума
• тестер – просто задолбал, хотя есть понимание, что сам налажал
• менеджер – зачем ему мои отчеты?
• уже знает свою рыночную стоимость, повышение ЗП не требует, но узнает о вакансиях на других фирмах, и иногда намекает о своей осведомленности
• если выполняемые таски и проект покажется не интересным, это негативно скажется на проекте – обычно сопровождается криками проект Г.., заказчик М…, и что Вы вообще понимаете в программировании

Senior Developer

• реалист, опираясь на свой опыт, видит "узкие" места проекта и закладывается на риски, а так же сообщает об этом менеджерам
• успевает и делать проект, и посидеть на "митингах", и еще и подсказывать коллегам
• может помочь ближнему, не стесняется сказать, что он чего-то не знает
• если и наступает на грабли – то тут два варианта:
1. "грабли" – легли в риски, и все проходит безболезненно
2. "грабли" – наносят критический урон по проекту, ибо Senior допустил ошибки при разработки архитектуры (иль еще где, но не менее фатально)
• удачно завершенный проект – доставляет истинное удовольствие (и психологическое и материальное)
• тестер – советник в плане юзабилити
• менеджер – щит, который тоже не любит неадекватного заказчика
• хорошо знает себе цену, не стесняется требовать повышения ЗП
• прекрасно понимают, что работа может быть рутинной, но это не должно влиять на качество кода, может ворчать, но работу будет делать

Если Вы располагаете достаточным количеством ресурсов, и при этом в наличии как Junior’ы так и Senior’ы – то судьба проекта может сильно зависеть от состава команды, так что будьте внимательны:

• не стоит ставить Junior’а к зубрам программирования, если среди них нет человека способного заняться его обучением: и новичок ничему не научиться, и “зубры” будут в бешенстве
• если проект разрабатывается лишь Junior’ами – держите руку на пульсе такого проекта и купите валерьянку – себе и заказчику ;)
• не стоит садить Senior’а за проект уровня “для чайников” – проект будет сделан и сдан, вот только разработчик от скуки начнет думать о работе в другом месте

Ну и еще немного информации к размышлению:

Ошибки которые совершают разработчики, когда начинают задумываться о повышении ЗП:

1. Переоценивают себя – требовать ЗП не соответствующую Вашему уровню – это верный путь остаться без работы
2. Устраивать сыр-бор за 10% прибавку к ЗП – зачастую такое повышение можно решить без лишнего шума и криков
3. Узнать, что через дорогу платят на 100$ больше, впасть в депрессию на пару недель, и оказаться на улице, ибо повышать ЗП человеку который последнее время ничего не делает никто не будет – это очень распространенная ошибка, никогда не забивайте на работу, будьте профессионалами.
4. Считать, что в соседней конторе работа в 100 раз интересней.

Другие посты на эту тему

• No Related Post

Это анонс проекта созданного участниками моей команды в рамках персонального обучения и развития.

Идея проекта банальна – генерация PDF документа из RSS каналов. В интернете Вы с легкостью найдете аналоги, но я уверен, что данный проект не останется незамеченным, и тому есть ряд причин:

1. Проект поддерживает кирилицу (за аналогами сего не замечалось)
2. Есть возможность кастомизации PDF документа
3. Интерфейс более дружелюбный

Проект разрабатывали Александр Денисенко и Михаил Турутанов, для них проект начинался как часть испытательного срока, а результат их работы Вы можете сами посмотреть и оценить.

TODO Проекта:

• Подружить проект с IE
• Сделать фильтр новостей по дате – Если rss содержит инфо за несколько дней, то нужно сделать функцию сортировки по дате
• Сделать возможность выбора целого блока новостей – по аналогии с GMail – зажимаем Shift – чекаем первый и последний элемент блока
• API для быстрой генерации PDF документа используя GET запрос
• Сделать цветовое выделение entries в списке – присводить каждому фиду цвет и подсвечивать соответствующие ему энтрисы этим цветом

P.S. В посте о Тестовом задании для разработчика меня упрекали в том, что задача притянута за уши, и что не надо тратить время на него, а лучше давать реальную задачу – PDFeed и есть такая задача, но она была поставлена только после выполнения “тестового задания”, таким образом я был уверен в том, что парни справятся с ней.

Другие посты на эту тему

• Zend Framework Day
• Мастер-класс Юры Артюха
• Мастер-класс по Sphinx
• Конференция ZFConf 2011
• ZFConf Ukraine
• Анонс мастер-классов по JavaScript’у
• Мастер-классы по JavaScript’у

Отношение менеджера к проекту

Менеджер не должен выражать своё отношение к проекту аля “проект полная ж…” (ППЖ) – таким образом он заранее настраивает разработчика на провал…

Отношение коллег к проекту

Видя что вашему коллеге достался проект из разряда ППЖ, не стоит выражать ему своё сочувствие словами “Проект тебе достался – ППЖ” – это не только ухудшит Ваши с ним отношения (слова “Тебе бы такой” может и не будут сказаны, но на языке точно будут крутиться), но и может навредить самому проекту…

Архитектура проекта

На разработку архитектуры зачастую уделяется мало времени, и очень зря. Необходимо приучить разработчика вначале продумать архитектуру до последнего винтика, а лишь потом писать код. А у нас, зачастую, “шашки наголо” и давай махать, нарубили дров, успокоились, и начали переписывать весь код наново – но бюджет проекта не резиновый – и это надо помнить не только менеджеру проекта, но и разработчикам.

И нечего пинать на реализацию, если архитектуру про…ли.

Дизайн проекта

Лучше когда дизайн есть с первого дня разработки, и тому есть несколько причин:

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

Но дизайн – дизайну рознь – он может стать раздражающим фактором на всё время разработки, так что если сделанный дизайн не нравиться нам, не стоит его показывать заказчику с надеждой – авось прокатит…

И еще процитирую Стива Джобса: “В речи большинства людей “дизайн” означает облицовку, но это совершенно не так. Дизайн — это основа и душа любого человеческого творения” – так давайте запомним это, и не будем создавать проекты-зомби…

Другие посты на эту тему

• No Related Post