Pull to refresh

Comments 79

А вы не думали оформить книгу в Apple iBooks Author?
По другим форматам и платформам думал, в планах есть. Посмотрим пока, каким тиражом книга разойдется :)
Как по мне, так если человек 100+ страниц своими ручками написал, так работу по переформатированию можно поручить кому-нибудь другому. Например, Вам. :)
Лучше в ТеХ'е начать оформление и выложить исходник, тогда энтузиастам будет проще.
Если хочется еще быстрее и проще — LyX.
Смотрите, чтобы ваш аккаунт Dropbox за большой трафик не заблокировал:)
Я поэтому и выложил дополнительно на Яндексе :) На данный момент 271 скачивания с Dropbox и 172 с Яндекса, помножить на три мегабайта, получается не так много :)
А в дропбоксе статистику ввели? Просветите как узнали что 271 скачивания?
Там сокращалка ссылок. Клики считать можно.
Не пали контору :)
UFO just landed and posted this here
Пока не получается: пробовал конвертить в EPUB, к сожалению, «всё плывет, все меняется» :(
А можно ее в doc кинуть в Kindle он конвертирует… Обычно все классно получается! Не удобно в PDF ее читать на ридерах…

P.S. Спасибо за руд. Полезная книга (по крайне мере выглядит полезной).
Еще было бы хорошо в .mobi, для kindle'ов.
Что мешает засунуть pdf в читалку?
Далеко не все читалки умеют форматировать PDF — они просто масштабируют страницу по размеру жкрана, и получается что на экране в 5 дюймов вы не сможете разобрать текст. Вторая проблема: даже если умеют, то не всегда корректно — в некоторых случаях появляются лишнии переносы (много лишних переносов), это очень сильно раздражает.
Естественно на читалках с большим экраном (напрример Kindle DX) таких проблем нет, там все ок.
Да, согласен, подумал про iPad, на котором читаю книги в PDF, но не подумал про телефоны.
На хабре был великолепный пост про решение этих проблем. Сейчас на 5 дюймах легко читаю PDF.
habrahabr.ru/blogs/ebooks/129397/
Это ворк эраунд. Смысл электронной книги — что бы было удобно читать. Описанный метод делает возможным чтение, но назвать его комфортным никак нельзя. Это как если купить себе хорошую, качественную обувь, но она вам будет немного мала.
Описанный метод подходит, когда в основном вы читаете книги в формате, который книга хорошо отображает и изредка необходимо прочитать такой PDF или djvu. Если же вы в основном планируете читать книги в PDF со сканами или в djvu, то не вижу смысла покупать маленькую читалку.
Опять же, все вышесказанное — субъективно.
Озвучу лично моё мнение. Есть у менять планшетик 1024*600. 11 дюймов. Читать неудобно. И есть мелкая читалка 5 дюймов. Читать удобно. А всё потому, что такую бандуру в одной руке держать неудобно, в автобусе неудобно, в очереди сидя — неудобно, в карман ложить неудобно, читать лёжа на спине неудобно — тяжело. А грамотно нарезав, экономится место, и становится читабельнее, чем на большом экране (800 точек по горизонтали + порезанные поля, против 600 на большом экране).
Повторюсь, мнение личное, но лишних переносов нет, читать вполне комфортно, 800 пикселей по горизонтали — это больше, чем у киндла.
Зачем сравнивать планшет и читалку? У меня на Kindle DX разрешение 824x1200. И 5-ти дюймовая читалка ну не может быть читабельнее как вы не порежете. А если в книге присутствуют рисунки, графики, диаграмы (на пол страницы и больше), то смотреть их на 5-ти дюймовой это издевательство.
попробуйте конверировать в нужный вам формат
Есть одна просьба, учитывать, что электронные книги на данный момент в основном черно-белые.
Это касается графиков и диаграм. Было бы неплохо использовать не только разные цвета, но и формы. Использовать различные линии на графиках (пунктир, точка-тире и так далее) и использовать различные штриховки для фона.
Я (скорее всего не я один такой) практически всю литературу читаю на электронных книгах, и вот эти моменты проблемные, приходится открывать на компьютере и смотерть нужные графики и диаграммы.
Форматы побороть еще можно (например купить Kindle DX или другой девайс с большим экраном) и тогда проблем с версткой и переносами в PDF нету, а вот что касается цветов — это никак :(
Да, за был добавить: за книгу спасибо!
Спасибо за идею.
Поддерживаю. Тоже читаю на электронночернильной книжке.
спасибо большое за труд. прочту с удовольствием.
> Можно сказать, что я отношусь к современному поколению управленцев, которые сочетают неплохое знание тяжеловесных подходов, но уверены, что настоящее и будущее за гибкими методологиями.

тут грамматический недочет: можно «сочетать А и Б» или «обладать А, но быть уверенным, что Б», а у вас тут смесь одного и другого.
Ой-ой, полистал дальше — содержание, похоже, прекрасное, а вот по части всяких мелочей русского языка нужна доработка
Грамматику лучше в личку или на мыло :)
Кстати, а почему не сделать эту публикацию вики-книжкой? Можно было бы молча поправлять и дополнять.
Привык в Ворде писать и в Визио рисовать. Я — раб Майкрософт :)
Некоторым удобнее читать на девайсах (телефон, планшет, электронная книга) и не всегда во время чтения есть доступ к интернету. Гораздо удобнее скачать и читать в подходящее тебе время.
Если сделать оба варианта (он-лайн и скачивание) — то их содержание будет разным (из-за внесенных дополнений или корректировок в он-лайн книгу), что вызовет путанницу.
Автогенерация оффлайн версии при внесении изменений в онлайн?
И Вы каждый раз будете перекачивать книгу? Просто может возникнуть ситуация, когда кто-либо ссылается на книгу (определенную её часть), а там на самом деле уже все по дргуому.
Я не говорю что предложенный Вами вариант не правильный, мое субъективное мнение, что книга должна быть фиксированной, а когда накапливается определенный набор правок и дополненией — делать переиздание.
UFO just landed and posted this here
Сейчас как раз изучаю «Управление проектами», и интересуюсь мнениями разных людей. Ночью обязательно почитаю. А вот грамматику, то что я заметила можно и через ОРФО проверить и подправить.
Ночью лучше спать, а не читать книги по управлению проектами :) Спасибо :)
Номера страниц в содержании не соответствуют действительности.
Проапдейтил на всякий случай. Спасибо.
В книге часть «Scrum в заказной разработке» два раза встречается? Стр. 29, стр. 46.
Спасибо. Запдейтил. Больше релизов на сегодня не будет: только вносятся ошибки дополнительные. :(
Пролистал, думаю читать будет интересно, спасибо :)
Что бросилось в глаза — у вас везде в книге используются картинки с пастельными тонами, а на 62-й странице таблица ну совсем из другого мира вырвана
Спасибо за обратную связь, посмотрю.
Забавно поведение людей, автор проделал огромную работу и не просит за нее денег, а все что вы тут можете обсуждать это «неудобный» PDF формат. Кошмар, ужас и позор.

Борис, спасибо за вашу работу.
Ничего, мы для дела ж. А не просить за работу денег — это уже перестаёт быть чем-то необычным, это просто клёво.
Не за что :) Если бы мне было просто отрендерить в другие форматы, я бы сделал :)
Спасибо! И за книгу, и за устраиваемые конференции. Уже давно ассоциируетесь с Agile.
Я в тела поста вставлю твою рецензию, если не возражаешь.
Да, без проблем, если не сложно, сохрани ссылку на мой пост.
Спасибо за то, что предоставили свой труд бесплатно.
Прочитаю, отпишусь.
Боря, ты молодец.

Первое, что сделал открыв версию 1.2 — это посмотрел раздел «инструменты Кайзена» в части про контрольные карты Шухарта. Стала ближе к правде, за двумя исключениями:
1. «В контрольных картах Шухарта для определения предела используется не стандартное отклонение, а размах.» — на самом деле даже не размах, а размах, усредненный по подгруппам, умноженный на некоторый табличный эмпирический коэффициент (дла размера подгруппы равного двум, этот коэффициент равен 2.66).
2. Отдельно подчеркну, что нельзя использовать такие карты напрямую для оценки сотрудников — Это тоже не совсем правда. Как ты правильно пишешь большая часть проблем относиться к процессам и сотрудники часто просто не могут на эти причины повлиять. и контрольные карты как раз расставляют все по местам, показывая где вина системы, а где сыграл человеческий фактор

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

А вообще очень интересно. Чуть позже вернусь и еще буду писать замечания. В конце концов, надо же хоть кому-то придраться к содержанию, а не формату файла.
Раздел «Как продать Scrum заказчику» оставляет впечатление, что Scrum нельзя продавать по Fixed Price. На самом деле имело бы смысл сказать, что это делать можно, но только после определенной подготовки: у нас должна быть хорошая зрелая команда, прошедшая вместе не один проект и было бы прелестно, если бы мы уже работали с этим заказчиком по T&M и предполагаем с ним работать достаточно долго. При таких условиях мы можем использовать статистические инструменты для определения конкретной суммы и конкретной даты поставки.

Другое дело, если мы с этим заказчиком делаем уже не первый проект (и делаем это хорошо), то вопрос о переходе на Fixed Price модель, как правило, не поднимается.
В качестве эпиграфа к «Эффект наблюдателя» ты процитировал Э. Деминга там, где он на самом деле цитировал Ллойда Нельсона: «Наиболее важные факторы, нужные для управления любой организацией, как правило, неизвестны и количественно неопределимы»

Я не придираюсь, просто показываю, что прочитал уже до 54й страницы.
Маленький комментарий к разделу «Что же делать?» в разделе «Эффект наблюдателя».

Первое, что нужно сделать — это дать самому себе честный ответ на вопрос: «Какие решения я буду принимать, на основании этой метрики?». Это поможет избавиться от большого числа метрик с диагнозом «Бесполезно».
Ограничение по срокам возникает как институт, который призван снизить риски заказчика.
Здесь как нигде очень напрашивается смягчающее «как правило» или «достаточно часто». Например, разработчики информационных систем к олимпиаде Сочи-2014 имеют вполне объективные дедлайны.
В главе про инженерные практики термин «Формальные инспекции кода» я бы заменил на просто «инспекции кода» или даже «Code Review».

«Формальная инспекция» — это все же отсыл к более тяжеловесным методологиям, где разделяют два вида инспекций: неформальные и формальные. Последние являются основанием для изменения статуса единицы конфигурационного управления. Миша Подурец (упомянутый в благодарностях), как мой бывший коллега, мог бы достаточно долго позанудствовать на эту тему.
И позанудствую: формальная инспекция в отличие от просто инспекции кода имеет критерии начала, окончания и, извините, здравого смысла.
Если у тебя нет хоть капельку формализованного процесса инспекции (минимум тяжести — хотя бы опорные пункты), то ты рискуешь (с хорошей вероятностью) получить спор сколько должно быть пробелов в отступах и где открывается скобочка: в конце строки или в начале новой.

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

Или есть у тебя гипотетически два способа реализации одного и того же алгоритма: простой и посложнее, но с оптимизацией по скорости. И вот если нет формального требования скорость оптимизировать — как выбрать наилучший?
В рамках терминологического занудства…
Фактически бережливое производство – это осмысление производственной системы Тойоты американскими учеными.
На самом деле бережливое производство — это осмысление американскими учеными осмысления японскими производственниками осмысления американских промышленников. Таичи Оно (японский производственник), при построении своей производственной модели опирался на учение Э. Деминга (американского ученого) и на идеи Генри Форда (американского промышленника)
На самом деле бережливое производство — это осмысление американскими учеными осмысления японскими производственниками осмысления американских промышленников.
Не только. Не будем забывать, что японцы очень много заимствовали из школ управления Советского Союза. Основные положения Кайдзен так это просто калька с официальной советской школы управления.
Я бы не согласился: в совке это все было на уровне лозунгов, а в Японии — это полноценная производственная культура.
> в совке это все было на уровне лозунгов, а в Японии — это полноценная производственная культура.
Во-первых это никак не мешало японцам копировать наши школы управления.
Во-вторых СССР был большой. На каких то предприятиях было так, на каких то по другому. Тут сказывается то, что я еще помню разнообразные радиопередачи и фильмы 70-80. Были, были у нас предприятия, где это работало.
Можно как цитату использую? :) Я так написал именно потому, что Деминг до Японии в штатах не был востребован.
Дочитал.

Действительно очень хорошая работа! Единственное опасение — в книге рассматривается очень много различных тем и местами весьма поверхностно. Иногда создается ощущение, что читателю с небольшим опытом больше половины идей будут непонятными. Было бы здорово силами сообщества и добровольцев подготовить версию 2.0, где затронутые темы будут рассмотрены глубже и шире. В итоге получится томик страниц под 300…
Я к концу весны видимо выдам вторую версию, где побольше распишу подробностей. По поводу участия «сообщества» я уже думал, пока, как я тебе уже говорил, сталкиваюсь с очень разными взглядами на одни и те же вещи, причем даже в самых простых вещах.
Отлично! Если на одни и те же вопросы существуют радикально отличные взгляды, то можно поднтся выше на такой уровень абстракции, где эти взгляды уже одинаковы.

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

Что-то типа того…
UFO just landed and posted this here
Матерые специалисты с седыми бородами настаивают на тяжеловесных методологиях с
сотнями ролей, процессов, артефактов и толстенными описаниями. Молодые управленцы
же предпочитают гибкие методологии или «Agile», как они говорят. Кто же прав в этом
противостоянии отцов и детей?

Любопытно. По моим наблюдения все с точностью до наоборот. Матерые специалисты с седыми бородами настаивают на «человекоориентированных» методологиях, а молодые управленцы
же предпочитают «процессоориентированные».

Возможно, это не расхождение наблюдений, а простая ошибка определения базовых терминов.
Мысль по поводу:
Не возьмусь утверждать это со 100% достоверностью, однако видится мне, что большинство команд, которые только начинают внедрять гибкие методологии у себя в проектах рискуют наступить на одни серьезные грабли. Грабельки эти заключаются в том, что большинство самых популярных книжек относятся как это ни странно к процессной части аджайла (как планировать, как показывать, какой длины выбирать итерацию, какие практики использовать и т.д.). А вот о том, как управлять собственно людьми (которые, как известно, важнее процессов) в таких книжках ни сказано, как правило, ни слова. Подразумевается, что об этом вы почитаете в других уменых книжках.
И вот процесс вроде бы поставлен, а профита нет. Реальная причина этому — люди. Точнее — неумение их готовить.

Так что спасибо, Боря, что хоть затронул эту тему.
Ровно так и есть и именно поэтому и на эту тему я проводил семинар «В России Agile нет. Почти.» Дай бог памяти… весной 2008.
Молодежь увлекается процессами и в итоге получает… э-э-э… очередную процессную методологию. А «Матерые специалисты с седыми бородами» уже знают, что люди важнее. И спокойно работают по Agile. Когда им это не запрещают напрямую.
Большая просьба писать английские слова английскими буквами или по возможности заменять на русские слова… А то канвасы, эпики и фасилитации сильно затрудняют чтение.
P.S. За книгу спасибо.
Спасибо огромное, как раз набираю материал для изучение Проект Менеджмента.
Sign up to leave a comment.

Articles