Мы ― небольшой коллектив (30 человек) который ведет один немаленький и достаточно успешный проект. У нас, как и у многих IT-фирм, были проблемы с документацией, планированием и организацией нашей работы. Вот уже полгода для коллективной работы мы используем Google Wave, который помог значительно продвинуться в решении вышеперечисленных проблем. И это несмотря на то, что продукт даже еще не в бета-версии.

Если вы ведете блог, то, возможно, вам знакомо чувство, когда взлелеянную, родившуюся в тяжелом труде статью никто не читает. И вы не можете понять причины. Кажется, и тема выбрана правильно. И стиль подобран адекватно. И слова использованы именно те, которые нужно! Статья написана интересно, и, бесспорно, должна быть полезной значительной части вашей ключевой аудитории…



Вы готовы воспринять это и адекватно отнестись, если сами чувствуете, где совершили ошибку, а где откровенно схалтурили. Знаете, что статья не дотягивает до уровня ваших привычных публикаций. Но если все сделано вроде бы правильно — можно попасть даже в глубокую депрессию из-за непонимания причин такого провала. Я промолчу о том, что мотивация к дальнейшему ведению блога испаряется пропорционально количеству таких «незамеченных» публикаций.

Привет, хабр.

Некоторое время назад я загорелась желанием изучать веб-дизайн и какой-нибудь язык программирования. И, конечно же, у меня возник закономерный вопрос «с чего начать». Более того, положение дел усугублялось тем, что никакого опыта ни в веб-дизайне, ни в программировании у меня не было вообще.
Что же делать? Как учиться самой? Куда двигаться, и за что хвататься?

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

Для начала большое спасибо хабру и хабролюдям, из статей и комментариев которых я вынесла нереальное количество полезной информации. Меня крайне вдохновила идея творческих блоков из этой темы, которые я и взяла за основу самообучения.

=========

Обновление от 24.03.13
Neatbeans 5.3 бесплатная IDE подходящая для верстки умеет на лету отображать набранный html в хроме через свой плагин.
Тоже самое умеет webstorm.
Куча костылей описанных ниже уже не нужны!

=========
Я хочу подвести итог инструментов-расширений Firefox для веб-разработки, благодаря которым у нас есть время на что-то более важное, чем верстка. Я поделюсь своими инструментами, а вы предлагайте свои.

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

Со многими вы знакомы, а что есть еще, или вы твердо убеждены, что у вас всего пара рук?

Начнем с самого известного:

1.

Говорят, если бы капитан мочевидность был веб-разработчиком, он бы всем советовал ставить Firebug. Это Джастин Бибер в мире попсы, это почти половина самого firefox.
В представлениях не нуждается, самая дописанная и навороченная панель разработчика FireBug есть только в Firefox.

По умолчанию в Google Analytics отслеживать взаимодействие посетителей с контентом сайта довольно просто. Используя стандартный код отслеживания, вы сможете получать различную информацию такую как: время проведённое посетителем на странице (time on site), показатель отказов (bounce rate) и количество просмотров (pageviews).

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

Мы хотим получать более детальную информацию по каждому сообщению или статье. Читают ли люди комментарии или только сообщение, статью? Открывают ли они во вкладках несколько сообщений?
Каким способом лучше получать детальную информацию о том как посетители сайта взаимодействуют с каждой страницей?

Эта статья о том, как измерить степень взаимодействия с контентом при помощи кастомизированного кода отслеживания Google Analytics (далее GA).

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

От переводчика. Данный текст является вторым текстом минисерии из 4 публикаций, посвященных социальным сетям и сообществам, их сходствам и различиям, а также их взаимосвязи друг с другом.

1. Сообщество или социальная сеть?
2. Как люди образуют связи
3. От слабых связей к сильным
4. Поддержание сильных связей

Автор этой серии публикаций — Майкл Ву (Michael Wu), ведущий аналитик компании Lithium, специализирующийся в изучении социальных взаимодействий и онлайн-сообществ.

---

В своей предыдущей публикации я обозначил некоторые базовые различия между социальными сетями и сообществами с точки зрения социальной антропологии. Если вы не видели этой публикации, рекомендую вам быстро ознакомиться с ней: Сообщество или социальная сеть? (Community vs. Social Network). Потому что сейчас я продолжу свои рассуждения на эту тему.

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

Я по образованию системный аналитик. За 5 лет учебы на данной специальности я понял, что системный анализ — это искусство решения проблем практически в любой деятельности человека. Не важно, что вы делаете — создаете стартап, открываете ресторан или организуете конференцию, если вы на первоначальном этапе хорошо изучите проблематику той области, в которой вы собираетесь произвести изменения, то эффективность вашей деятельности увеличиться. Не даром говорят, выявленная проблема — это 50% решения.

В этой статье я хочу поделиться одной идеей для стартапа, которая появилась из жизни. Дело в том, что я люблю посещать всевозможные события: концерты, фестивали, опен эиры и т.д. И в том месте, где я сейчас обитаю, вокруг меня происходят десятки разных событий (подобная ситуация свойствена всем большим городам). И передо мной периодически возникает следующая проблема: каким образом быть в курсе всех актуальных и интересных событий, проходящих вокруг меня. Я начал изучать эту тему и понял, что на данный момент в интернете отсутствует эффективное решение по поиску событий. Более того я исследовал ситуацию еще и со стороны организации событий, что тоже показало свои проблемные области. Под катом вы можете ознакомиться с результатами моего небольшого исследования.

Сразу хотелось бы определиться с некоторыми понятиям, дабы никого не провоцировать на полемику из-за недопонимания ключевых моментов. Так же хочу предупредить, что это не руководство к действию и не пособие, а всего лишь рассказ в стиле «как это делают другие».

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

Важным этапом научного исследования является выбор темы и оценка степени разработанности проблемы. В современных условиях лавинообразного роста информации проблема выбора тема усложняется еще больше: ученый оказывается просто не в состоянии отслеживать все публикации в собственной области (не говоря уже о смежных областях). Кроме того, на начальном этапе исследования достаточно сложно (кто писал кандидатскую диссертацию, тот знает) отслеживать процесс изучения собственной области на современном этапе (т. е., получать актуальную информацию о том, кто, где и чем занимается, какие публикации выходят, какие диссертации защищаются и т. п.). В настоящее время данная задача облегчается при помощи научных социальных сетей, позволяющих ученым отслеживать (а в некоторых случаях — и скачивать) последние публикации по собственной, устанавливать контакт друг с другом, а также предоставляющих некоторые дополнительные возможности. Рассмотрим некоторые популярные социальные сети для ученых более подробно. Данный обзор не претендует на исчерпывающий характер; при выборе социальных сетей я руководствовался следующими критериями: 1) интернациональность (именно поэтому в обзор не попали сервисы, ориентированные на ученых какой-то одной конкретной страны) и 2) междисциплинарность (в первую очередь меня интересовали социальные сети, которые могут использоваться учеными самой разной специализации; именно поэтому обзор не затрагивает сервисов, ориентированных на представителей какой-то одной конкретной дисциплины). Буду очень рад, если с помощью читателей удастся расширить и дополнить этот список.

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

Введение

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

Мы все хотим ставить перед собой и своей командой четкие и понятные цели (задачи), для этого существует несколько критериев, которые собираются в английскую аббревиатуру SMART (умный):

Буква	Английский термин	Русский термин
S	Specific	Точные и конкретные
M	Measurable	Измеримые
A	Achievable	Достижимые
R	Relevant	Релевантные
T	Time bound/framed	Цели со сроком

Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.

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

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

Все звучит довольно просто и логично, но нашей команде удалось сделать ретроспективы полезными и эффективными далеко не сразу.

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

Среди моих знакомых нет ни одного, кто любил бы писать технические задания или что-то вроде этого. Чертить на салфетках планы захвата вселенной, собирать лэйауты из разноцветных стикеров, шлифовать концепцию в голове и на словах – это все любят и умеют делать, а вот сесть и как следует записать…
Меня, например, любой шаблон серьезного документа погружает в глубочайшую тупку.

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

Начну я просто — поясню, что такое Scrum и зачем он нужен, что бы те люди, кто с ним пока не сталкивался, могли с интересом прочесть данную заметку и понять о чём собственно идёт речь.

Итак, Scrum, это популярная (модная, если хотите) сегодня методология ведения программных проектов. Другими словами, как управлять командой разработчиков, что бы программный проект завершился успешно. Что и как документировать, как, с кем и как часто обсуждать детали проекта, как ставить задачи людям и как контролировать результат. Всё это попадает под термин “методология управления программным проектом”.

Вам понятно? Отлично! А теперь…

Этот топик, есть продолжение вот этого топика: habrahabr.ru/blogs/pm/39308

Итак. Продолжим повествование на тему Скрама.

Перед тем, как описать саму методологию, чуть коснёмся классификации. Часто приходится слышать: у нас XP методология, а у нас Скрам, а у нас Agile девелопмент. Всё это имеет право на жизнь. Но, на мой взгляд, желательно правильно соотносить эти понятия.

XP — это набор принципов и подходов, меняющих традиционное отношение к разработке современного программного продукта.

Agile – это общее название группы гибких и достаточно успешных методик организации ведения проектов. Методик, которые, как правило, опираются на принципы XP и предполагают быструю итеративную разработку, тесное общение с заказчиком и, за счёт тесного общения членов команды, минимизацию создания дополнительных сущностей (артефактов/документов), которые традиционно создавались в процессе работы над проектом. Минимизацию всего того, что создаётся помимо самого программного кода.

Scrum – это одна из конкретных Agile-методик. То есть чёткий шаблон (каркас) организации управления проектом. Со своими терминами и понятиями. Если вы близко следуете именно этому шаблону, то можно сказать, что вы ведёте разработку по Скрам.

Я часто сталкиваюсь с другой классификацией, когда XP называют Agile методологией. Сложно сказать…

Хабралюди! Меня уже какой день мучает вопрос: а что не хватает современным web-based системам управления проектами? Я уверен, что многие из вас работают в командах, при этом разнообразных. У некоторых есть офис, а некоторые разбросаны на сотни километров друг от друга. Так вот: чем вы все пользуетесь? Что устраивает, а чего не хватает? А главное — о чем мечтаете? =)
Заранее спасибо за все ответы.

«Теория кратковременных направленных толчков» или что надо знать сотрудникам или руководителям друг о друге и о своей компании, чтобы жить дружно и добиваться результата…

Я склонен утверждать, что эта теория применима к коллективам численностью от 10 до 200 человек. Хотя последние наблюдения за государством, армией и большими компаниями начинают убеждать меня в том, что все используют ее, но не признаются в этом :)

Изначально это была секретная теория :) Т.е. сотрудники компании не должны были знать ее, чтобы не противодействовать выполнению планов. Но сегодня я убежден, что понимание отношений внутри коллектива необходимо всем сотрудникам, так как без этого вообще иногда не удается решить застарелые проблемы или понять причину поступков руководителей и сотрудников. Ну и просто это открывает еще большие возможности по достижению выдающихся результатов в компании.

Иными словами я рекомендую данную статью для прочтения как директорам компаний или руководителям отделов, так и сотрудникам компаний. Вдруг пригодится :)