Главная / Библиотека /  Беседы и Лекции по Менеджменту / Как ориентироваться в программинге с точки зрения менеджмента, или Надеть трусы Барбары Стрейзанд

Как ориентироваться в программинге с точки зрения менеджмента, или Надеть трусы Барбары Стрейзанд

Эля: Высылаю переписку с Хаафом по проекту «H», о том как ориентироваться в программинге с точки зрения менеджмента. Как ставить задачи, как их контроллировать и что там важно. Думаю, всем будет полезно и интересно. (Авторская орфография и пунктуация сохранена)

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

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

3. сюда же — большие проекты нельзя запрограммировать на ходу. нужно много подумать в начале. если программер подходит типа «ну щас все напихаем, а потом оно заработает» — этого не случится если он подходит «кого волнует что там внутри, оно же работает» — тоже ничего не будет

4. сюда же — при передаче проекта между программерами нужен специальный протокол :):)

Под протоколом имею в виду следующее:

1. разбираться в большом чужом коде — сложно (если только писал не очень очень хороший профессионал) и неприятно, очень неприятно. Это как тебя заставляют надеть трусы барбары стрейзанд :):) потому что оказывается что очень многих вещей ты сделать не можешь или какие-то очень простые вещи делаются через четыре жопы или «вся архитектура построена на том, что в главное меню вернуться нельзя» :):) - это одна половина.

вторая половина — лень и халява

2. если полпроекта уже написано — так давай быстренько допишем до конца, не будем переделывать (так могут думать даже не плохие программеры) и на этом попались «M», т.е. между трусами барбары и халявой второе пересилило.

для управления программингом — критично видеть этот порог сложности, признаки того что он скоро будет достигнут — я написал выше в примерах отношения программеров :)

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

Эля: — ага, что нужно делать, если он уже наступил? какие правильные действия? Меня с Димой сейчас тревожит этот вопрос. Он мне сказал, что по хорошему нужно все переписывать заново. Насколько реально, что они исправят баги и мы не потеряем время впустую?

Хааф: — по хорошему нужно стараться вести проект так, чтобы это не случилось в течение разработки, т.е. количество «степеней свободы» в проекте постепенно уменьшается почти всегда.

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

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

Ты можешь даже сама это сделать, тут нужна просто абстрактная логика. увидеть все баги и как-то их обобщить одним названием не всегда это сможешь сделать ты, но тогда надо либо позвать кого-то умного, либо попросить-поговорить с программерами. Можно просто спросить — что самое злое и вонючее? Они тебе и расскажут сами, просто они в пылу работы не всегда могут сами обобщить и принять решение, но все признаки они тебе назовут, потому что у них от них болит голова :)

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

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

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

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

Его же нужно знать при передаче проекта другим программерам. если система гибкая, стабильная — нет проблем, если она близка к порогу сложности — нужно выделить «зоны риска», «зоны рефакторинга» и заставить нового программера с ними разобраться, иначе он потом увязнет. Это же кстати на мотивацию к проекту влияет про «сложность», «рефакторинг» и «порог» — все.

Еще кое что о программинге :)

Программерам очень, критично важно, знать о проекте ВСЁ. начиная от общего списка частей, масштаба проекта, до последних мелких деталей, как какая-то функция должна работать и это очень большой объем информации, поэтому, особенно, если программеров несколько, или есть вероятность того, что проект будет передаваться между ними, очень важно иметь один общий полный документ, описывающий проект, т.е. иметь 5 разных документов, описывающих разные чати проекта — мало, они могут быть, но тогда должен быть еще один документ — описывающий все эти части вместе и их взаимодействие и это должна быть аккуратная пачка файлов с говорящими названиями, потому что это — основное с чем работает программер на входе. и эта инфа должна быть доступна одновременно. т.е. если ты передаешь программеру половину ТЗ, а вторую обещаешь через 2 недели — очень велик шанс что эти 2 недели ничего делать он не сможет, или если сможет — то потом увязнет.

Почему это так важно — программеру нужно сначала в своей голове, а потом в программе придумать как это все разделено и связано друг с другом, начиная от глобальных решений типа какие у нас объекты вообще есть? как они связаны? что они могут друг от друга требовать? например, забыла ты сказать программеру что кроме интерактивных экранов будут еще заставки-мультики — у него проблема, забыла ты сказать что какие-то экраны анимируются, а не просто картинки — у него проблема, не сказала в конце «это, парень, всё. больше не будет. зуб даю!» — у него проблема, он в подвешенном состоянии, потому что не знает, как планировать систему... до мелочей совсем типа когда я нажимаю кнопку — она должна сначала загореться или после? когда я ввожу строку длиннее 10 символов — как она влезет? и т.д. вот он все это должен продумать, по аналогии с дизайном — от общей композиции до последних точечек-рюшечек на кнопочках, только в пространстве ЛОГИКИ понятно что в чистом виде ВСЁ известно не бывает. но вывод отсюда такой — стремиться как можно точнее описать задачу, стремиться поддерживать документацию в актуальном состоянии, обновлять как только что-то изменилось и держать в аккуратном, собранном виде. Главное — как можно точнее зафиксировать хотя бы общую логику и стараться ее не менять потом.

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

По коду даже готовому можно понять что система уже делает, но невозможно понять, что она ДОЛЖНА делать, отсюда практически нет способа это продолжить, хотя бы потому что не видны узкие места. Вот.

Дальше у меня есть еще пара моментов более технических и про Диму.

Технически — программмерские проекты удобно вести с багтрекером, у вас это Jira и Ворушин сказал ты уже умеешь ею пользоваться.

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

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

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

В нем же есть способы разибвки багов на категории и приоритеты, плюс тебе не нужно дожидаться личного контакта чтобы выдать задание — занесла в трекер, поехала на встречу, если проект хорошо разогнан — вернулась, а он уже исправлен, ты и сказать ничего не успела, хотя так ты была бы вынуждена дожидаться программера в скайпе, например, потом ему объяснять, а потом еще не быть уверенной в том что он запомнил, записал это по трекерам, если Jira слишком сложная — есть более простые, Trac например. Можешь поспрашивать команду Ворушина, они посоветуют.

И про Диму

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

Главное — ты должна ориентироваться в общей скорости проекта и сроках до тех пор пока сильного отставания нету — все ок. что такое «сильное отставание» нам станет ясно, когда составим списки из них будет примерно видно на что сколько времени нужно и сколько есть. с Димой нужно постоянно держать контакт, если ты с ним неделю не общаешься — лажа, т.е. нужно как-то помириться, чтобы вы друг у друга неприятных эмоций не вызывали :) чтобы между вами ходила информация по работам и по оценкам сроков. понятно, что программеры тебя накололи :):), но как-то постарайся не переносить это в будущее, это губит, может мы вообще облажаемся, но это не должно влиять на отношения, потому что Дима делает все возможное. Умел бы лучше — сделал бы.

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

1 октября 2008 г. КСАН.

Материалы по теме:

Рецепт Стаса, или Как правильно планировать время, чтобы не подохли мотивации
Разгон потока — одна из главных задач менеджера
Не запараллеливать процессы
УЧИТЬСЯ БЫТЬ СТРАТЕГОМ