Questions to the contractor
How was the work on the website organized? What did the interaction with the ordering party look like?
The portal should have been made as an informational resource, using which you could have left as well a request to rent a flat or cottage in the new building city of Skolkovo Innovation Center. In other words it should have been uniting the function of attraction of new lease holders and reputational constituent.
In order to determine definite waymarks of the project and speak the same language with the ordering party, we developed a detailed prototype and made the SOW on it's basis.
As the city was being built (the construction continues at the moment) and at the moment of project start not all residential areas were finished by the real estate developer, the ordering party didn't have a clear vision of how to organize the whole process of renting. They had only general view on it. To clarify business details and specificity we organized meetings several times with ordering party representatives. But mainly, in order to save time, all questions were discussed in online mode via Skype.
In order to determine definite waymarks of the project and speak the same language with the ordering party, we developed a detailed prototype and made the SOW on it's basis. These works took us about 2 months. By that, significant part of time was spent on approving and confirmation of the results by the ordering party side.
As the result, we got a concrete vision of final results instead of bleary outlines as before the beginning, but still for a variety of reasons we didn't get a chance to work out the whole functionality on the SOW stage, so it was decided to think over several questions after first project integration. For example, set of functions of the online account, authorization through "Virtual Skolkovo" AIS (put simply, www.sk.ru Skolkovo website authorization system) and other.
The project software development was based on company accepted agile-methods directly. The project was divided into circuits, for either of which a detailed plan was drawn. During the development process many objections were changed, new objections appeared, that's why the initially written SOW was used more like a reference book, and not like a strict instruction manual, that is, in general, characteristic for agile methods of software development.
Huge portal — is always some kind of an iceberg, where only the top can be seen. Tell more about project architecture.
Huge new progect doesn't appear as an iceberg from the horizon, but grows gradually, accreting new sections.
That's why, in order for the site not to turn to a huge snowball, it's necessary to approach the question of development and implementation of new functionality with a special care.
LEADING DEVELOPER, INTARO
The SK website includes several main functions: informs visitors about Skolkovo region, latest news and events, and also provides convenient search mechanisms, renting and apartment maintainance, offices and services.
Several technological solutions are used to maintain these tasks on the project. The website is built on the CMS 1C-Bitrix platform, that allows to lead fast and effective development and implement new functions.
The website is closely integrated with the rest of Skolkovo ecosystem: synchronization with inner management system allows to receive actual information about services and apartments availability, and also transfer data collected on the website for processing. Users of the "Virtual Skolkovo" portal may login on the website in one click and use all its capabilities completely.
What is the most interesting technological part of the project?
As it often happens, the most interesting, at the same time the most difficult part of the project is inner system design, setting and managing all content and objects needed for realization of set tasks, and also forming up connections with external systems and relevant integration protocols.
Taking into account that project work was held by small circuits, we needed to project scalable structure from the very beginning, tha would be friendly to further setting and implementing of new functional capabilities.
What was the most difficult on the project in terms of management?
Collection and consolidation of objectives definitely. I will explain why: from the ordering party side several functional aquirers took part in the project, that could make decisions. In some cases it happened uncoordinately, sometimes decisions contradicted already realized logical circuitry, but it was impossible to cancel or postpone them. Unfortunately, we managed to get the requests acquisition process going only by the end of the first stage. Further work on the project, that is being held at the moment, is built already on more exact communication conditions.
In this case initially well-considered scalable architecture helped us to hold control over the project. That is what Eugene was already talking about. And also usage of flexible agile-methods, which are designed for leading such specifical projects.
As we've got to know the work on the project was held by short circuits. What happeed before such half way deadlines to keep the schedule?
As you know, intensity of fulfillment processes is usually shifted closer to the end of the project/circuit. This project wasn't an exception. To keep initialy confirmed terms we tried to increase team productivity. We recruited additional resources as and when necessary. We reconstructed earlier set task priorities in real time mode taking into account current ordering party and project needs in general.