№ 220 | Библиотека Сайтостроительства - новости, статьи, обзоры
Приветствую всех читателей рассылки! В прошлом выпуске публиковалась ссылка на мой довольно краткий обзор сервиса "BobrDobr", сегодня в догонку дам ссылку на интервью с директором по развитию сервиса Сергеем Житинским, в котором он делится планами на великое будущее; Для вас же, уважаемые мои, возможно, будет интересна информация о вакансии у БобрДобра: компании БобрДобр.ру требуется
на постоянную работу пишущий человек. Работа предполагается следующая: ведение корпоративного блога; написание популяризаторских статей и размещение их в блогах и информационных ресурсах; комментарии в блогах, где пишут про социальные закладки и/или про БобрДобр. Прежде всего эта вакансия будет интересна тем, кто жаждет попробовать себя в роли community-менеджера - сотрудничество с интересной и сильной командой (это я точно знаю :) ), с уже известной в рунете компанией может оказаться очень полезным как самой
компании, так и кому-то из вас, мои хорошие. Пишите Сергею Житинскому или, к примеру, мне (внизу выпуска есть мейл), дополнительные вопросы можно задать в блоге - отвечу и, в случае чего, проконсультирую.
Меня же, как и очень многих современных разработчиков по-прежнему волнует бесконечная тема планирования и организации процесса разработки, а так же внутрикомандные отношения. Так складывается, что для большей части проектов в одиночку, будь ты хоть семи пядей во лбу талантище и гений, никак не справиться. Над современными веб-проектами работают совместно администраторы, программеры, дизайнеры, проектировщики, работает большая команда. Ясно, что чем больше команда, тем сложнее ею управлять. Поэтому хочу поделиться
с вами одной не такой уж и давней, апрельской заметкой о проектирвоании:
Вот и прочитана за выходные дошедшая меньше чем за два месяца из первопрестольной книга Алана Купера "Психбольница в руках пациентов", и вот что интересно. И - ничего. Не изменилось видение мира, не определились варианты решения проблем, жизнь продолжается так же, как и до прошедшей пятницы. А вот теперь интересный ход: через пару недель мои программеры тоже прочтут эту книгу, т.е. (я понимаю, что в масштабах вселенной смешно звучит, но) сложится
хоть и не большое, но сообщество из менеджеров (ставящих тз или управляющих разработкой), frondend и backend программеров, кодеров и дизайнеров. Вот в таком сообществе в целом изменится ли хоть что-нибудь? Отношение к своей работе, к разрабатываемым творениям, к своему будущему?
И без тезисов Купера на небе только и разговоров, что о море в IT только и разговоров, что о необходимости проектирования и убыточности эрзац-проектирования. И в реальных проектах у нас до сих пор только и споров между постановщиками и разработчиками о том, что "сделайте по-быстрому тестовый модуль..." - "давайте сначала продумаем проект в целом!.." - "это долго и убыточно!..." - "переделывать проект, который вы будете "наращивать" на этом тестовом модуле - ещё более убыточно..." - и вот
так постоянно, практически в каждой подгруппе наших программеров.
Кто-то более упёртый и уверенный в себе настаивает на предварительном проектировании и создании "правильного", кому-то проще послушно лепить таблицы в базе, добавляя к ним поля и связи, не задумываясь об оптимальности работы базы данных и о скорости выполнения запросов - а нам-то что? Заказчик сказал, мы - сделали. Что, запрос выполняется от 40 секунд до полутора минут? Что, непродвинутый пользователь сервиса считает, что сделал что-то неправильное и убегает от монитора, а опытный считает, что это "зависла
винда" и закрывает окно браузера?? Проблемы взаимодействия пользователя с тулзом пусть решает дизайнер.
И дизайнер решает. Чтобы пользователь не закрыл окно или не сбежал куда подальше - его нужно предупредить о том, что всё нормально - выводим ему сообщение "please, wait...", что идёт генерация его данных. Он может не увидеть текстового сообщения (он же не ожидает информационного сообщения, он ожидает данные) - значит, его внимание нужно привлечь какой-нибудь анимированной картинкой, "прелоадером" (вот кстати вам отличный тулз на большое количество миленьких прелоадеров,
которые генерятся нужного вам цвета и под нужный вам фон).
И всё-же приятно, когда некая задача, необходимость решения которой ещё несколько месяцев назад никто (из заказчиков-постановщиков) ещё не видел, вдруг выплыла, и я очередной раз могу сказать вслух: "ну я же говорила!" - и меня послушали, и мы заложились на то, что этот сервис всё равно понадобится (просто клиент ещё не созрел к концу прошлого года), и теперь понты делов - добавить одну форму в интерфейс. А если бы меня не услышали тогда, осенью - гм. нифига бы у нас не получилось, или отказываться от этой
функции, или переделывать чуть ли не полностью всю основу проекта - базу, связи, типы данных. Получилось смешно - заказчик сам не ясно видел цель своего проекта. Для меня же проект обозначился мгновенно - кто им будет пользоваться, как и что понадобится в ближайшее уже время. Оки, заказчику нужно было просто поюзать готовое решение. Несколько месяцев практического использования с реальными данными и живыми деньгами. И заказчик увидел её - эту цель - уже достаточно чётко и ясно.
Обычно же чудес не бывает. У заказчика нет чёткого видения проекта, т.е. он не может высказать это видение проектировщику-постановщику, те не могут озвучить задачу разработчику-программеру, тому, в свою очередь, совсем не прёт проявлять инициативу, напрягать свою интуицию, активизировать творческие способности и закладываться под что-то, о чём не сказано. Плохой проект, не нужный тулз, кривой сервис разработать очень легко. Но уже правильное видение цели может поспособствовать тому, что и реализация будет
совсем другой. Так происходит в IT разработках, так происходит в обычной жизни.
Вот ближайший пример (бытовой) приведу:
Даю дитёнышу деньги и ставлю задачу: купи, малыш, подкопеченных сосисок грамм 500-600.
И ухожу на работу, и приду поздно вечером.
Дитёныш идёт в магазин и обнаруживает, что подкопченных сосисок нет. Есть разные варианты решения. Ребёнок принимает решение взять 300 грамм менее вкусных и менее качественных "молочных" сосисок. Почему? Потому что он видит цель не как "выполнить поручение мамы", а как "в доме закончилась еда, нужно обеспечить еду". Вот в чём разница! Здесь
понадобилось проявить инициативу: если бы он ничего не купил, меня вечером ожидал бы сюрприз в виде пустого холодильника, а время - уже не магазинное (ну и заодно без завтрака бы остались). Если бы он купил менее качественные, но в указанном в исходном задании объёме - мы бы получили 600 грамм фигни, которой давились бы несколько дней. Решение, принятое дитёнком, было оптимальным - обеспечить минимум для того, чтобы преодолеть кризис. А завтра будет день, может - появятся деньги на мясо и время на то, чтобы
это мясо приготовить, а нет - привезут в магазин качественные сосики, но кризис - не наступит. Правильное видение цели.
Не только недостаточное проектирование, но и ошибки существующего проектирования есть практически в каждом первом проекте. Такой уж безупречный анализ можно провести для маленького-премаленького проектика с минимальным количеством входных данных и ещё меньшим (одним) исходящим результатом. Для больших проектов продумать всё на этапе проектирования шансов мало, хоть что-то, да будет упущено, поэтому на исполнителей-разработчиков в любом случае ложится задача в той или иной степени додумывать, напрягать врождённую
интуицию и логическое мышление. И у нас разработчики есть разные. Есть публика, которая тихо и покорно исполнит добуквенно поставленное задание. Что, через три месяца окажется, что база не оптимальна, крива и бездарна - ставьте другое задание, переделаю. Есть противные упёртые программеры, которые не начинают работу, пока не переругаются со всеми постановщиками, заказчиками и менеджерами, но - заставят заказчика (постановщика) думать. Есть ребята с развитой интуицией, которые ни с кем не ругаются, тихонько делают
своё дело, а когда доходит до новых фич и сервисов - опаньки, а нефиг делать, одна форма, два чекбокса, три часа на доработку!
Конечно, всё должно быть правильно. Конечно, рамки ответственносит должны быть формализованы заранее, конечно, за качество проектирования должен отвечать проектировщик, за качество программирования - программист. Но в реальной жизни чрезмерная формализация приведёт к 100% ухудшению ситуации с проектом, от программиста можно и нужно ожидать инициативы (в рамках поставленной задачи). Больше или меньше - всё равно требуется принимать решения и брать ответственность за решения.
Бытовые ассоциации:
Прошу дитёнка купить пачку сока. Всё.
Дальше, уже без меня, ребёнок анализирует ситуацию. Он помнит, что последние несколько месяцев я домой приносила яблочный, реже - морковный сок. Значит нужно выбирать тот или другой. Он видел, что я покупала сок в 2-х литровых пачках. Значит, требуется принести такую-же 2-х литровую. Денег - соответсвует этому объёму. Он приходит в магазин - того сока, который требуется купить, в нужных объёмах нет, есть только литровые упаковки.
Решения:
1.
(безинициативное) ничего не покупать, потому что нет решения, точно соответствующего поставленной задаче
2. (инициативный, но рискованный) Купить сок в пачке другого объёма, отличного от заявленного мною, т.е. 1 литр.
3. (инициативный и тоже рискованный) Купить сок в литровой пачке в количестве двух пачек.
Две пачки по одному литру стоят на несколько десятков копеек дороже чем одна двухлитровая. Но ребёнок принимает решение из третьего варианта. В принципе в любом из трёх вариантов можно придраться
и отругать за неверный выбор - в первом - оставил без сока, во втором - купил меньше, чем ожидалось, в третьем - заплатил дороже, чем ожидалось. Дитёнок делает свой выбор и готов нести ответственность за этот выбор. Задача настолько мелкая, что обращаться к постановщику для того, чтобы кореллировать начальные условия и пересмотреть ТЗ - даже смешно. Так можно дойти до того, что не вставать с постели без указания - с какой ноги это нужно делать.
Может показаться, что я пытаюсь оправдать руководство, не желающее уделять достаточное внимание предварительному проектированию всего и переложить ответственность за выбор правильного решения на конечного разработчика. Нет, не пытаюсь и не оправдываю и не перекладываю. Просто иногда наблюдаю ошибки, очень странные для человека, считающего себя адекватным разработчиком с развитым логическим мышлением, способным вообще, по-жизни принимать разумные решения.
А вот пришло уведомление о выходе очередного, уже 4-го номера Юзабилити бюллетня, где очень в тему обнаружилась ссылка на перевод статьи Скотта Беркуна "Почему большинство программ такие отстойные":
Как получаются хорошие вещи
Во время творческого процесса вы упражняетесь в деле вселенских масштабов – создании чего-то нового, доселе не виданного. Делать что-то для других – дар. Немногие на земле обладают привилегией зарабатывать на создании вещей. Если вы их создаете для себя - вы и разработчик, и заказчик. Но если вы творите для других, вы не получаете дар, вы сами дарите.
Большинство людей не умеют дарить подарки, даже себе, поскольку мы не всегда
знаем, как сделать счастливыми себя, не то, что других. У каждого из нас за всю жизнь наверняка скопилась куча ненужных подарков от людей, которые были безразличны, невнимательны, лицемерны, скупы, вульгарны, не имели ни вкуса, ни талантов, либо просто не знали нас достаточно хорошо, чтобы подарить нам что-то приятное. Плохие программы – это плохой подарок. Все причины плохих подарков в равной степени относятся к плохим программам.
Все хорошее в этом мире создается людьми со щедрым складом ума. Они всегда
думают о тех, для кого творят. Они искренне стараются сделать что-то, что удовлетворит потребности других. Они стремятся потратить время и силы на совершенствование своих мыслей и навыков с тем, чтобы в конечном итоге создать и подарить этому миру что-то хорошее. Они рассматривают свою работу как высшую степень благородства, олицетворяющую их собственные идеалы качества и искусства.
Хорошие программисты, дизайнеры, архитекторы и просто творцы в любой области - прежде всего, люди думающие. Они настолько одержимы
созиданием, что готовы изучить любую дисциплину, прочесть любую книгу, выслушать любого человека и развить любой навык, чтобы совершенствовать свое умение создавать стоящие вещи. Для них не существует границ науки, зоны ответственности, собственной должности, когда речь идет об идее, способствующей им в создании чего-то хорошего.
В комментариях к этой заметке в блоге практикующие программисты тут же принялись обсуждать "культ думающего программиста", особенно понравилась такая формулировка:
Думающий программист -- это плохо для проектов, все остальные члены которых не-думающие. Это диссиденство, и последующая ссылка в сибирь.
Думающий программист -- это хорошо для проектов, в которых все программисты думающие. Это творческий подход, реализация того что должно быть, а не того о чем мечтал заказчик в нежном возрасте. Это возможность сделать проект быстрее, выше и сильнее.
Не-думающий программист -- это хорошо
для тоталитарных проектов, для конвейеров или для подобных строгих вещей. Он делает то что ему сказали, и соблюдает букву спецификации практически до последнего слова. Если же буква не соблюдается, то она не соблюдается вообще. Кода для этого -- нет. И ничего не нужно переделывать. Это радость постановщику и менеджеру, и бессонные ночи для заказчика, когда он понимает что ему дают именно то, что он подписал... А не то что будет работать.
Не-думающий программист -- это плохо для проектов,
в которых каждый пишет подчиняясь общему духу, создает вещи, которые красивы сами по себе, просты, функциональны и надежны, в которых каждый элемент (блок, модуль) рассчитан на многократное использование... Это наказание для тимлидов, которым нужно по два часа описывать буквально по точкам, что и куда поставить.
Вы сами, уважаемые, понимаете, что озвученное не ограничить программерской частью команды. Инертный скучный менеджер или руководитель вполне может сам завалить работу целой группы программеров-энтузиастов, а ленивый дизайнер, формально подходящий к задаче - испохабить вообще всю работу над проектом. Как можно гарантированно избежать этого - рекомендаций может быть бесконечно много, но каждая опять же может быть абсолютно бессмысленной в частной ситуации - здесь играет роль и везучесть руководителя (и каждого
из участников проекта), и энергичность, заинтересованность в успешной реализации, и бюджеты - не в последнюю очередь, чего уж там. Обсудить заметку можно в Блоге NunDesign на LJ - пишите, уважаемые, жду ваших комментариев.
Н O B O C T И
:: Рейтинг ИТ-брендов: русские наступают
Информационно-деловой канал @ASTERA представляет результаты исследований в рамках проекта «Рейтинг ИТ-брендов» – по итогам 1-го квартала 2007 года. Данные исследования проводятся уже четвертый год подряд....>>
:: SEO и отделы сбыта
Оптимизация и раскрутка сайта – это не набор готовых шаблонных правил, во многих случаях требуются нетрадиционные решения и творческий подход....>>
:: 6 выпуск юзабилити-бюллетня
30 марта 2007 года Юзабилити Бюллетень зарегистрирован как электронное периодическое издание. В шестом выпуске – ссылки на статьи и обзоры по юзабилити....>>
:: Популярность в сети – рутина или искусство?
Для оптимизаторов раскрутка сайта в Сети равно тождественна оптимизации сайта для Поисковых систем. Здесь как в спорте – выигрывает тот, кто опытнее, способен принимать быстрые решения и лучше технически подкован....>>
:: Webby Award: Самый красивый сайт года
Самое большое эстетическое наслаждение в этом году жюри Webby Award, самой престижной премии Интернета, доставила flash-анимация и айдентика сайта, произведенного силами одного сингапурского дизайнера в качестве своего же портфолио....>>
:: Будущее HTML
Подход Web Hypertext Application Technology Working Group к усовершенствованию HTML...>>
:: Photoshop CS3 Extended: то, чего никто не ждал от Photoshop
Примерно за месяц до официального релиза компания объявила, что кроме обычного Фотошопа будет еще и особенная версия, рассчитанная на архитекторов, инженеров, 3D-художников, аниматоров и ученых....>>
:: Web 2.0 в порталах
BEA Systems выпустила новую версию своей системы построения порталов – BEA WebLogic Portal 10. В компании особо выделяют новые возможности продукта, отвечающие технологиям Web 2.0. ...>>
:: Adobe сделает инструмент для веб-разработчиков Flex проектом open-source
Компания Adobe Systems намерена сделать Flex, свою среду разработки для создания приложений на базе механизмов Flash и Apollo, проектом open-source...>>
:: iGoogle персонализирует страницы
Компания Google переименовала в iGoogle сервис, позволяющий изменять домашнюю страницу поисковика, и позволила пользователям создавать собственные гаджеты....>>
:: Веб-разработчики 2007
Все материалы прошедшей недавно конференции для веб-разработчиков РИТ 2007 доступны в разделе Программного комитета. По мере появления свежих версий презентаций, текстов и видеоматериалов организаторы обещают публиковать их на странице соответствующего доклада....>>
:: Webby наградит рекламистов
В этом году на премии Webby будут награждаться не только сайты, но и онлайновое видео, мобильные сайты, а также – интерактивная реклама....>>
:: Новая игрушка от Яндекса – пульс блогосферы
На Поиске по блогам Яндекса появился инструмент для оценки и измерения общественного мнения в интернете...>>
:: Результаты второго исследования контекстной рекламы
Важно отметить, что тенденции, отраженные в исследовании характерны не только для указанной выборки, но и для большинства пользователей систем контекстной рекламы в Рунете....>>
:: Компания «Караван» провела исследование рынка выделенных серверов
Наиболее активные пользователи услуги colocation/dedicated отрасли, напрямую связанные с рекламной деятельностью (19 рынка) и продажей через интернет (15). Следом за ними идут компании, поставляющие товары (13)....>>
:: 25 мая – бесплатный семинар по анализу, продвижению и управлению ресурсом
На семинаре будут рассмотрены вопросы продвижения сайтов в интернете, анализа аудитории сайта и оценки эффективности рекламных кампаний с помощью программных инструментов....>>
:: ClickDensity – новая буква в веб-аналитике
Идея карты кликов давно уже лежала на поверхности, однако из-за того, что юзабилисты на Западе совсем уже отдалились от технарей, ее почему никто не брался реализовывать....>>
:: Google проведет всемирный «день разработчика»
31 мая Google проведет сразу в 10 странах 27-часовой всемирный «день разработчика» – Developer Day, призванный заинтересовать программистов созданной в компании платформой Web-сервисов, сопутствующим инструментарием и API-интерфейсами....>>
:: Разработана уникальная платформа управления wap-сайтами для бизнеса
WapFace позволяет всем заинтересованным в новой аудитории брендам быстро и удобно создавать собственные мобильные сайты за считанные минуты....>>
:: Adobe представила новый медиаплеер
Adobe Media Player – это настольное приложение для воспроизведения флэш-видеофайлов....>>
:: Web 2.0 не работает?
Скептики все больше говорят о том, что Web 2.0 — никакая не революция, а очередной «мыльный пузырь». Теперь их правота подтвердилась исследованиями, ясно показавшими: концепция Web 2.0 не работает....>>
:: Рынок цифрового контента растет как на дрожжах
Многое изменилось после покупки компанией Adobe компаний Macromedia и Serious Magic, Autodesk – компаний Alias и Colorfont, а Google – компаний Sketchup и YouTube. Все меняется прямо на глазах, и это хорошо......>>
Автор: Татьяна Вукс
Источник: Библиотека Сайтостроительства
|
|
