Как организовать исследовательский проект

Благодаря творческим усилиям моих коллег, все проекты оказались успешными. Журнал «Экономическая социология» прочно занял свою профессиональную нишу, число его читателей ежегодно возрастает. Эксоцентр превратился в один из наиболее посещаемых ресурсов по разделу «Наука/Социология». А Федеральный образовательный портал, содержащий уже десятки тысяч ресурсов, в течение длительного времени занимает одно из первых мест среди профессиональных образовательных ресурсов Рунета. Таким образом, оставаясь дилетантом в области технологии, я приобрел некоторый организационный опыт, которым и хотел бы поделиться, чтобы другие коллеги по возможности избежали принципиальных ошибок (которые мы, увы, порою допускали).

Как построить отношения с разработчиками технологий

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

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

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

Главное преимущество стандартных решений состоит не в том, что они непременно предоставляют больше возможностей (хотя зачастую это действительно так), а в том, что их развитием занимается параллельно множество специалистов и фирм, которые без особого труда могут заменить друг друга. Однако стандартные технологические решения, использующие известные платформы, как правило, более дороги, понадобится закупать соответствующие лицензии. И потому многие идут, как им кажется, более прямым путем – делая «дешево и сердито». Сердито, потому что рискуют, как говорят порою, «сесть на иглу», попав в зависимость от услуг, предоставляемых отдельной фирмой.

В связи с этим предложим следующее правило:

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