Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

27.04.2017

Google
WWW CITForum.ru
С Новым годом!
2003 г

Структурное руководство проектом. Серебряная пуля?


Издательство: КУДИЦ-ОБРАЗ
Алексей Закис
ООО ИК СИБИНТЕК

"Кстати, если вампиры на вас все же нападут, [...] с серебряными пулями лучше не баловаться. Ерунда все это, сам пробовал"

Емец Д.А. Таня Гроттер и трон Древнира

Оказывается, серебряная пуля для ИТ проектов появилась уже 10 лет тому назад! А теперь про нее можно прочитать и по-русски. Вот только так ли она действенна, как принято считать?

Увы, разработка программного обеспечения остается одним из самых рискованных занятий. Процент неуспешных проектов, в том числе не уложившихся в сроки или бюджет, наиболее высок именно в области информационных технологий и именно среди проектов, связанных с разработкой ПО. Можно долго рассуждать, почему проекты проваливаются. А можно подумать о том, почему же часть проектов все-таки выполняется успешно. И по второму пути идут очень и очень многие. Существует масса рекомендаций касательно того, как нужно выполнять проект, чтобы "наверняка" или "почти наверняка" выполнить его в срок, в рамках бюджета и удовлетворить все пожелания Заказчика.

Чтобы тебя заметили в такой ситуации, новая методология должна называться как-то очень необычно. Ну, например, "эКСтремальное Программирование", "Кристально ясная", или хотя бы "Рациональный Унифицированный Процесс". А что делать, если новый метод называется просто "Структурное руководство проектами"? Ничего выдающегося... Приходится придумывать запоминающееся название для книги, описывающей вашу методологию.

Именно так и поступил Фергус О'Коннэл, дав своей книжке с достаточно скучным названием "Как успешно руководить проектами" подзаголовок "Серебряная пуля". Собственно, под этим названием она и известна среди англоязычных специалистов. А теперь ее можно прочитать и по-русски (Фергус О'Коннел. Как успешно руководить проектами. Серебряная пуля. М.: КУДИЦ-ОБРАЗ, 2003. - 288 с.).

Для тех, кто не знает. Серебряная пуля - это не только радикальное средство от вампиров. Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.

Назвать книгу с описанием своей методологии "Серебряная пуля" - это серьезная претензия. И нельзя сказать, что она необоснованна. Как-никак, на английском первое издание "Серебряной пули" вышло в 1993 году. На русский язык книга переведена с третьего издания, вышедшего в 2001 году. Значит, интерес к ней не пропал. Значит, в ней действительно есть что-то важное и полезное, не потерявшее своего значения за 10 лет достаточно бурного развития ИТ. Но, с другой стороны, ведь и спустя десять лет мы говорим все про те же проблемы...

Сам автор говорит, что он написал книгу не про Методологию, а просто про методологию. В чем разница? Чем структурное управление проектами отличается от многочисленных методологий разработки ПО, хотя бы от упомянутых выше?

Самое главное отличие состоит в том, что это книга написана для руководителей проектов. И ТОЛЬКО для руководителей проектов. В ней нет попыток объять необъятное и дать рекомендации и ценные указания всем участникам разработки. Конечно, никто не запрещает читать ее аналитикам или программистам. Но в узко профессиональном смысле они не найдут там почти ничего, адресованного именно им. Зато если вы руководите проектами или собираетесь этим заниматься, то эта книга для вас. В ней описано, что должен сделать человек, руководящий проектом. В каком порядке. И как проверить, что он сделал все как надо.

Суть структурного руководства проектами заключена в 10 этапах, через которые нужно пройти, выполняя проект:

  1. Наглядное представление цели; сосредоточьтесь на призе.
  2. Разработка списка задач, которые должны быть выполнены.
  3. Должен быть только один лидер.
  4. Закрепление людей за задачами.
  5. Управление ожидаемыми результатами, расчет резервов для ошибок, выработка запасных позиций.
  6. Использование подходящего стиля руководства.
  7. Знание того, что происходит.
  8. Информирование исполнителей о том, что происходит..
  9. Повторение этапов 1-8 до этапа 10.
  10. Приз.

И если вы сумеете выполнить их, успех вашему проекту гарантирован.

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

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

А что получат от участия в проекте остальные его участники? А что получит Заказчик? Чему будет радоваться он?

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

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

Второй этап, я думаю, уже вызвал возмущение среди многих приверженцев современных методологий, которые выучили, что "водопад - это плохо" (имеется в виду водопадный стиль разработки, когда сначала осуществляется анализ, потом последовательно проектирование всей системы, разработка кода, сборка и комплексная отладка). Но обратите внимание на этап 9! Основной особенностью структурного управления проектами является то, что задачи, которые необходимо выполнить для выполнения проекта, выявляются как можно раньше. Как только вы поняли, что вам придется это делать - запишите! Вот, собственно, и вся суть этапа. При этом, как и в большинстве современных методологий, разработка ведется итерациями. На ближайшую итерацию (обычно, длительностью от 4 до 6 недель) составляется точный и детальный план. На остальные - более общий и приблизительный. Но если вы знаете, что через три итерации вам придется настраивать СУБД для обеспечения максимальной производительности системы, то и запишите это прямо сейчас! У вас будет лишнее время, чтобы подумать, кто и как будет выполнять это работу.

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

Пожалуй, я бы добавил к данному разделу, что Руководитель проекта должен обладать достаточными полномочиями. Мало того, чтобы все управление проектом шло через единственного Руководителя. Этот Руководитель должен обладать существенными правами в части формирования цели и планов выполнения проекта, возможности непосредственно договариваться с Заказчиком, поощрения и наказания участников и много чего еще. Только в таких условиях единоличная ответственность за выполнение проекта не раздавит, а мобилизует руководителя проекта.

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

Возможных исполнителей для каждой задачи можно разделить на несколько категорий. Лучший вариант, если человек заведомо может и при этом хочет выполнить именно эту задачу! Несколько хуже, если его приходится уговаривать (возможно, в следующий раз уговоры не подействуют). Если он недостаточно квалифицирован, но, тем не менее, готов взяться за задачу - его можно обучить (если на это есть деньги и время). Значительно хуже, если он не хочет за нее браться или не может с ней справиться даже после обучения. Хорошо, если для такого сотрудника есть другие задачи, которыми он хочет и может заниматься. Если нет - увы!

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

И еще один момент, о котором часто забывают. Административная работа тоже требует времени! И чем больше участников в проекте, тем больше времени нужно на администрирование. Соответственно, и нагрузку на себя руководитель должен планировать с учетом административных задач. Чтобы сократить объем административных задач для Руководителя (например, если он превосходит естественные возможности) можно ввести среди участников проекта внутреннюю структуру и назначить руководителей групп. В этом случае административную работу придется планировать и для них. Причем учтите, что если у вас нет обученных и проверенных руководителей групп, в начальный период вам придется тратить на работу с ними существенно больше времени, чем на рядовых подчиненных!

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

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

Пятая стадия знаменует завершение планирования очередной итерации. Теперь пора браться за выполнения планов. И здесь правила не сложнее.

Стадия шесть. Определите, кто из исполнителей требует какого контроля с вашей стороны. Идеальный исполнитель выполняет все, что ему поручили. За другими приходится следить, контролировать скорость выполнения, помогать принимать технические решения... С первыми работать приятно. А с остальными - необходимо. Увы, надо больше времени уделять тому, что необходимо. Таким образом, стадия переходит в принцип: "уделяйте больше внимания тем, кому ваша помощь необходима".

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

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

Ну а еще нужно контролировать ход проекта по косвенным признакам. Если люди получают удовольствие, - скорее всего, все идет нормально. А вот если есть проблемы в личных отношениях, никто не радуется, то это подозрительно. Даже если проект пока идет по графику.

Стадия восемь. Информация о ходе выполнения проекта должна быть доступна всем: участникам проекта, Руководству и Заказчику. Может быть, не все должны знать все в полном объеме. Но лгать нельзя никому. Идеальное решение, это еженедельный отчет. Желательно сделать его многоуровневым. Так чтобы на самом верхнем уровне можно было получить ответ на вопрос "Проект в графике?". А на нижнем - сведения по отдельным задачам.

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

И так до конца итерации. Потом повторить все с самого начала. Не забудьте проверить, не изменились ли ваши цели! Спланируйте следующую итерацию. И выполните ее.

И вот после последней итерации вы, наконец, завершили этот проект! Как пишут в рекламе, вы это заслужили! Но пока все еще в памяти, не забудьте подвести итоги. Что оказалось не так, как вы предполагали изначально? Почему?

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

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

Но вернемся к началу. Сумел ли автор найти серебряную пулю? Неужели разработка ПО остается рискованной только потому, что не все прочитали эту книгу?

Честно говоря, странное ощущение осталось у меня после этой книги. С одной стороны, ну что здесь нового? Все содержание книги можно пересказать в одной фразе. Тщательно управляйте проектом!!! Именно так, с тремя восклицательными знаками. И это - чудодейственная серебряная пуля?

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

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

Но если все так просто, то почему же мы никак не забудем про проекты, не уложившиеся в график, в смету, а то и вовсе завершившиеся пшиком? И даже не исследовательские, экспериментальные, прорывные, а такие скромные, типовые проекты...

Потому, что научить правильному стилю руководства очень сложно. Если вы прочитали книжку по UML, то, худо-бедно, вы будете рисовать и понимать UML диаграммы. Если вы прочитали руководство по IDEF1, вы будете понимать диаграммы в нотации IDEF1. А если вы прочитали книжку по структурному управлению проектами, вы, конечно, можете выучить 10 стадий. Но не факт, что вы сумеете их применить.

Вы не верите? Начнем с ключевой стадии. Готовы ли вы признать, что, если проект провалился, то это именно вы лично как руководитель проекта привели его к провалу?

На словах все мы готовы согласиться с тем, что Руководитель должен отвечать за проект. А на деле часто думаем примерно так: "Но ведь я хороший! Это вот только подчиненные мне достались так себе, если не сказать прямее… Иванов в три раза дольше, чем было запланировано, возился со своим модулем! А Петрова вообще в декрет ушла! А кем я ее заменю? А Сидоров? Ну, переназначили его пять раз на новую задачу до того, как он предыдущую доделал. Но ведь это для проекта так нужно было, а он обижается! И после этого, вы скажете, что я плохо руководил, и поэтому проект затянулся на три года вместо шести месяцев? Да дали бы мне нормальных программистов, я бы... А если я планы не писал, так это для того, чтобы больше времени самому программировать. Если бы не я, вообще неизвестно, закончили ли бы мы этот проект хоть когда-нибудь!"

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

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

Если же вы все-таки сумеете переломить себя и тщательно спланировать проект… Пусть даже не в MS Project, и даже не на бумаге, а в голове по дороге на работу… Если вы будете помнить, кто из разработчиков чем занят, и тщательно продумывать, кому какую следующую работу лучше назначить… Короче, попробуйте, а вдруг у вас получится!

Ну и еще одно замечание. Даже с самыми замечательными серебряными пулями, чтобы проект был выполнен качественно и в срок, нужно много пота. В том числе от Руководителя проекта. Не скажу, что это гарантирует успех. Скажу по-другому, это делает успех возможным.

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

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...