Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>Я задался целью доказать этой статьёй, что ценности и принципы гибкой разработки программного обеспечения применимы в разных областях деятельности. Пусть это будет мое любимое коммерческое писательство.</p>

2 <p>Поехали!</p>

3 <h2>Содержание</h2>

4 <ul><li><a>Ценности Agile</a></li>

5 <li><a>Люди и взаимодействие важнее процессов и инструментов</a></li>

6 <li><a>Работающий продукт важнее исчерпывающей документации</a></li>

7 <li><a>Сотрудничество с заказчиком важнее согласования условий контракта</a></li>

8 <li><a>Готовность к изменениям важнее следования первоначальному плану</a></li>

9 <li><a>Принципы Agile</a></li>

10 <li><a>Наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения</a></li>

11 <li><a>Изменение требований приветствуется, даже на поздних стадиях разработки</a></li>

12 <li><a>Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев</a></li>

13 <li><a>На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе</a></li>

14 <li><a>Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им</a></li>

15 <li><a>Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды</a></li>

16 <li><a>Работающий продукт - основной показатель прогресса</a></li>

17 <li><a>Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно</a></li>

18 <li><a>Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта</a></li>

19 <li><a>Простота - искусство минимизации лишней работы - крайне необходима</a></li>

20 <li><a>Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд</a></li>

21 <li><a>Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы</a></li>

22 <li><a>Послесловие</a></li>

23 </ul><h2>Ценности Agile</h2>

24 <p>Назовём их вечными.</p>

25 <h2>Люди и взаимодействие важнее процессов и инструментов</h2>

26 <p>Ты можешь обложить себя "Главредами" и "Орфограммками", использовать "Слово*б", чтобы подобрать ключевые слова для статьи. Это, в принципе, неплохо. Однако не стоит за всем этим забывать о здравом смысле и необходимости "полевых" работ. Никто лучше тебя, человек, не проведёт анализ ЦА, не выявит конкурентов и не интерпретирует полученные данные. Да, сервисы (например, PR-CY) облегчат рутинные операции, но сделать выводы и познакомить с ними клиента можешь только ты сам.</p>

27 <h2>Работающий продукт важнее исчерпывающей документации</h2>

28 <p>В применении к моей области это означает, что лучше, чёрт возьми, написать и опубликовать одну статью, чем месяц корпеть над контент-планом, а в результате полностью от него отказаться.</p>

29 <h2>Сотрудничество с заказчиком важнее согласования условий контракта</h2>

30 <p>Ты имеешь полное право дотошно выяснять все нюансы по ТЗ, по заполнению брифа, по срокам сдачи текста и оплате. Главное - не потерять за этим возможность (иногда необходимость) общения по сути проекта. Копай глубоко, выясняй неявные детали и подводные камни бизнеса клиента, сообщай ему о них и получай обратную связь. Это нормальные человеческие и деловые отношения.</p>

31 <h2>Готовность к изменениям важнее следования первоначальному плану</h2>

32 <p>Речь про правки, порой жестокие и кардинальные. От правок не уйдет никто: ни программист, ни копирайтер, ни дизайнер. Ни даже жена, которая сварила борщ, а он тебе показался недосоленным.</p>

33 <h2>Принципы Agile</h2>

34 <p>Они настолько хороши, что часть можно взять не только в работу, но и в жизнь.</p>

35 <h2>Наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения</h2>

36 <p>Всегда укладывайтесь в дедлайны и работайте на опережение, но не в ущерб качеству. У меня часто случалось так, что ранняя сдача статей приводила к тому, что я узнавал и быстро устранял различные недочёты и ошибки.</p>

37 <p>Иногда нашему брату нужно работать на упреждение. Если же мы говорим про новостной контент, то этот принцип отрабатывает на все 146 %.</p>

38 <h2>Изменение требований приветствуется, даже на поздних стадиях разработки</h2>

39 <p>Если ты должен внести существенные правки в текст за 15 минут до публикации, сделай же это! Да, это может "поранить" структуру, отвлечь тебя от более приятных занятий. Но положительный читательский отклик все окупит сторицей. Проверено.</p>

40 <h2>Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев</h2>

41 <p>В случае с коммерческим писательством - ещё чаще - каждый день, а то и несколько раз в день. Разный по тематике и формату контент привлекает больше людей. Тут главное "не перекормить" читателей.</p>

42 <h2>На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе</h2>

43 <p>Священное правило копирайтинга. Даже если ваш клиент скажет "я в этом ничего не понимаю, делайте сами", поверьте: когда он станет проверять продающие тексты, сделанные без его участия, резко появятся все возможные компетенции и адские правки ваших маркетинговых измышлений. Поэтому с самого начала работайте с клиентом. У вас общая задача - заработать как можно больше денег.</p>

44 <p><em>С самого начала работайте с клиентом. У вас общая задача - заработать как можно больше денег</em></p>

45 <h2>Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им</h2>

46 <p>Большой и сложный проект предполагает работу команды из редактора (редакторов) и коллектива авторов. Например, в веб-агентстве "Текстерра" мы с друзьями-коллегами писали книгу о разработке сайтов для начинающих, в работе над которой участвовал ваш покорный слуга. Мы с самого начала разделили обязанности - кто и какую главу пишет, кто и чьи тексты редактирует. В итоге получился отличный продукт, на который до сих пор приходят благодарные отзывы.</p>

47 <h2>Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды</h2>

48 <p>В любой социальной сети и любом мессенджере (я уже не говорю про CRM) можно создать чат с коллегами и обсуждать любые рабочие вопросы. Это могут быть ежедневные планерки и мозговые штурмы. Порой простой треп двигает рабочий процесс лучше, чем натужное выдавливание ценных мыслей!</p>

49 <h2>Работающий продукт - основной показатель прогресса</h2>

50 <p>Коммерческий автор, как и программист, "измеряется" выполненными работами. Говорить, что ты что-то делал, "а эти вон всё запороли" - профессиональный моветон. Сделал - покажи, не сделал - промолчи.</p>

51 <h2>Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно</h2>

52 <p>Чем успешнее блог, тем выше требования к редакторам, авторам, дизайнерам и верстальщикам. Малейшее отклонение и всё - "блог скатился", "вы пишете ахинею" и т. д. и т. п. Это тяжело, но в нашем деле нужно фигачить, чтобы хотя бы стоять на месте. Сейчас даже полезного контента много: стремитесь делать его уникальным, чтобы конкуренты о таком только мечтать могли.</p>

53 <p><em>В нашем деле нужно фигачить, чтобы хотя бы стоять на месте</em></p>

54 <h2>Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта</h2>

55 <p>У нашего брата-писателя это означает создание и развитие редакционной политики блога - добавляйте новые требования и убирайте старые, чтобы все работало на рост качества контента.</p>

56 <h2>Простота - искусство минимизации лишней работы - крайне необходима</h2>

57 <p>Если что-то можно сделать автоматизированным способом, сделайте это! Следуйте правилам редполитики, и это существенно облегчит жизнь и вам, и редакторам с клиентами.</p>

58 <h2>Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд</h2>

59 <p>Потому что энтузиазм - великая вещь. Если несколько авторов собираются вместе, они способны решать куда более широкий круг задач, чем автор-одиночка, какой бы крутой он ни был!</p>

60 <h2>Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы</h2>

61 <p>Для этого и проводятся планёрки, где каждый может сказать, что он видит хорошего и плохого в работе блога и коллег, дать им советы и высказать новые идеи.</p>

62 <p>Та же редполитика - не раз и навсегда определенный документ. Если она не работает в текущих реалиях - в пекло её! Создавайте новое, берите "свежих" авторов, не бойтесь ЦА: сегодня они гневно реагируют на ваши контент-новинки, а завтра репостят их везде, где только можно.</p>

63 <h2>Послесловие</h2>

64 <p>4 ценности и 12 принципов Agile, как видите, хорошо ложатся на коммерческое писательство. Подставьте сюда "медицина", "строительство", "военное дело": стоит только чуть-чуть подумать и сформулировать свои мысли, чтобы понять, что в феврале 2001 года семнадцать программистов дали миру универсальный набор правил ведения профессиональной деятельности. Аминь.</p>

65 <p><em>Статью подготовил Алексей Александров, коммерческий автор, писатель и сценарист. Профили автора:<a>"ВКонтакте"</a>,<a>Facebook</a>.</em></p>