Вот такой список обнаружил когда-то в одном давно заброшенном блоге англоязычного менеджера проекта. Адрес блога к сожалению давно потерялся, но сами список с небольшими исправлениями оказался очень полезным в работе — еженедельно просматриваю его. Очень помогает приводить мысли и информацию по проекту в порядок.

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

Читал и я, даже возмущался: «Нет, ну как же можно по телефону кому-то там сказать свой пароль». Но, увы, лучше всего запоминается удар граблей по собственному лбу. Так и вышло. За последние пару месяцев я стал свидетелем и даже участником нескольких ситуаций, о которых рассказывать стыдно, но социально полезно.

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

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

Суть эксперимента

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

Мы промониторили несколько десятков подобных обсуждений за последние несколько месяцев и выявили следующее…

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Как художник на свою картину маслом, как молодая мамаша на своё обожаемое дитя, веб-разработчик глядит на дело рук своих — сайт, и изъянов никаких за ним не замечает. Трезво взглянуть на результат своего труда, не упуская ни одной мелочи при сдаче проекта, чтобы не подвести требовательного заказчика, помогает чек-лист.



Итак, самый эффективный чек лист для проверки готовности сайта эксклюзивно для читателей блога Webprofessionals.ru:

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.

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

Внутри — сам чеклист и примеры из нашей практики.

^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

Проверьте свой проект: вы летите или думаете, что летите?

Ниже вопросы, которые стоит задавать себе на старте проекта и время от времени на его протяжении.

Контрольные вопросы на старте проекта:

1. Что конкретно нужно сделать на текущем этапе? В целом? Есть ли чётко определённые цели каждого этапа? Как вы определите, что цели достигнуты? Соответствует ли текущий статус заявленным планам и целям или их необходимо корректировать?
2. Реалистичны ли эти цели?
3. Что случится, если цели не будут достигнуты в срок? Каков план действий?
4. Насколько этот проект значим? Например, зависит ли от него место вашей компании на рынке?
5. Какую выгоду вам, обществу и инвесторам принесёт проект?
6. Достаточно ли хорошо спланирован проект? Все ли в вашей команде понимают пункты плана одинаково?
7. Нужны ли внешние эксперты, например, юристы?
8. Есть ли у команды опыт работы вместе? Кто будет координировать команду? Важно ли для проекта работать именно вместе — или возможен труд одиночек? Отвечает ли каждый член команды за работу всех остальных?
9. Можно ли сократить размер команды? Если нет, то почему? Если да, то почему это не сделано?
10. Как вы будете компенсировать форс-мажоры с персоналом, например, что случится, если ваш ведущий разработчик сломает руку?

Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

Те, кому в гуглотаблицу не хочется, просим под кат. Там перевод.

Небольшой и полезный чеклист по usability. Проверьте свой ресурс перед тем как перейти к юзер-тестированию. Не претендует на «столп usability», которому необходимо следовать, но здесь собраны довольно полезные вещи.

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

Что делать дальше и на что не забыть обратить внимание.

Довольно часто на сайтах е-коммерса нас просят реализовать фильтры. Хороший фильтр — довольно дорогая игрушка. Вообще, они не всегда уместны — пользователю проще посмотреть глазами на список, чем разбираться в логике разработчика фильтра. Конечно, если в этом списке не так много элементов. Скажем, не больше 200 в каждом разделе. Ниже в виде проверочного списка для наших QA, я зафиксировал некоторые требования, которые мы настойчиво внедряем на своих проектах с этого года. Стандартизация, ептэ.

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

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

По данным MarketingSherpa покупатели, которые используют поиск по сайту, совершают покупку в 2-3 раза быстрее, чем другие. Для десятков миллионов покупателей поиск – это самый удобный метод для того, чтобы найти нужную им информацию в дебрях сайта. Когда речь идет об интернет-магазинах, жизненно важно помочь посетителю в его поисках. Вот несколько критериев, которым должен отвечать любой поиск:

Основное:

1. Поместите окно поиска на каждой странице вашего сайта.

2. Оно должно легко находиться. Обычно пользователи ожидают увидеть его в верхней части экрана.

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

В компании Wild Apricot, где я работаю, мы используем чеклисты как один из инструментов для контроля качества релизов достаточно широко. У нас это список действий, которые надо обязательно выполнить что бы фича ушла в релиз. У нас есть чеклисты разработчика, тестировщика (о!.. сколько у тестировщиков тест-листов...), и даже чеклист аналитика и дизайнера. Сравнительно недавно я занимался его переработкой и хотел бы поделится уроками, которые при этом получил.

Глеб Летушов, редактор-фрилансер, адаптировал для блога Нетологии чеклист с Github от David Dias. Этот чеклист уже переводили, но так как на Хабре его нет, мы решили, что он пригодится. В чеклисте собран полный список элементов, которые необходимо проверить перед запуском и публикацией сайта.



Список основан на многолетнем опыте фронтенд-разработчиков, а дополнения собраны из общедоступных источников.

Общий принцип — Не делай брак.
Не бери брак. Не передавай брак.
Тойота.

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

«Почти» по сетке

Сетка призвана упрощать вёрстку и определять местоположение ключевых элементов. В некоторых случаях дизайнеры намеренно отходят от 12-колоночного грида для создания неординарного дизайна.

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

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

Переносили все системы: тестовые среды, тест + прод, препрод, все виртуальные машины, виртуальные сервера плюс все системы виртуальной инфраструктуры. Даже поддержка у них своя появилась в России. От нас — только аренда ресурсов.

Проверяли они нас знатно, по масштабам: почти полный аудит ЦОДа. Но они смотрели не железо и теххарактеристики в основном, а то, как выстроены процессы ИБ и как соблюдаются разные SLA. С их точки зрения, именно процессы по стабильности SLA указывают на качество работы компании. И мы им рассказывали про каждый из компонентов детально.

Я хочу поделиться списком критериев к проверке. Потому что появилась хоть какая-то методология, ведь до этого мало какой заказчик так системно подходил к вопросу.

Привет! Меня зовут Олег, и я frontend-разработчик в Альфа-Банке. Я хочу рассказать вам немного философскую историю — про инженерный подход к разработке, про мою первую работу и грабли, которые я там собрал, про то, почему чеклисты очень важны (и спасают жизни).

А еще про то, как продолжать продуктивно работать и не закопаться во множестве мелких и не очень задач.

Всё началось с хаоса.

SCRUM стал настолько популярен, что сейчас его пытаются внедрять практически везде. В больших компаниях иногда получается так, что SCRUM внедряют ради отчетности, или для того, чтобы быть “прогрессивным” и “модным”. В результате ситуация, что вроде как ответственный менеджер поставил себе очередную галочку, мол, надо было внедрить методологию — внедрил, молодец, но при этом вместо каких-то качественных улучшений на выходе оказывается так называемый «Zombie SCRUM». Это когда формально фреймворк внедрен, но по нему никто нормально не работает. Отсюда и название.



Меня зовут Олег Егоркин, я agile коуч в Ростелекоме, и в этом посте я расскажу, почему «зомби-скрам» вообще возникает, как этого избежать и как убедиться, что в компании все готово к запуску скрам-команды.